ServiceComb

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 转载本文需注明出处：微信公众号EAWorld，违者必究。 引言： 微服务倡导将复杂的单体应用拆分为若干个功能简单、松耦合的服务，这样可以降低开发难度、增强扩展性、便于敏捷开发，从而被越来越多的开发者和公司推崇运用。但系统微服务化后，一个看似简单的功能，内部可能需要调用多个服务并操作多个数据库实现，服务调用的分布式事务问题变的非常突出，几乎可以说是无法避免。 分布式事务已经成为微服务落地较大的阻碍，也是较具挑战性的一个技术难题。那么我们在实际开发中需要如何去应对呢？本文将介绍在实际微服务开发中分布式事务的实战。 目录： 1.分布式事务讲解 2.分布式事务解决方案-servicecomb-pack 3.分布式事务实战讲解 1. 分布式事务讲解 1.1事务原理 在讲分布式事务之前，先聊一下事务。简单讲事务是数据库管理系统执行过程中的一个逻辑单元，它能保证要么一组数据库操作全部执行成功，要么全部失败，而做到这些的原理就是事务的ACID四大特性。 A. Atomic原子性的简称，事务作为一个整体来执行，要么全部成功，要么全部失败。 C. Consistency一致性的简称，事务应确保数据从一个一致的状态转变为另一个一致的状态。 I. Isolation隔离性的简称，多个事务并发执行时，一个事务的执行不影响其他事务的执行。

序   南京奇蛙智能科技有限公司，聚焦于发展工业级无人飞行器，在无人机领域有十年技术和经验积累，其智慧控制业务在无人机领域拥有核心竞争力，贯穿端到云的全流程，向用户提供实时直播、远程控制及多屏/多人互动的无人机管理和信息共享，覆盖公共安全、环保气象、能源电力等领域。 奇蛙联合ServiceComb打造无人机“微”大脑   奇蛙智能科技智慧控制业务，以云端飞行控制系统为中心，辐射地面综合管理和增稳云台，为用户带来现场和远程遥控无人机，完成数据采集、视频直播、实时操控等良好体验。多样化用户体验、全天候待命、复杂环境飞行等场景，对飞行控制系统的安全、快速、精准提出了很高的要求，构建高可靠、高性能、易扩展的飞行控制系统显得至关重要，奇蛙联合ServiceComb微服务开源社区，共同打造智慧控制的云端“大脑”。 “微”操作，指令立达，更流畅   无人机行业云化需要支持高实时高可用场景，其作业任务需要对多客户端无人机数据实时上报、指令实时到达，时延不高于20毫秒才能保证操作流畅。在无人机配合人群疏散、抓捕拦截等作业任务中，要求全方位监控地面/空中可疑情况，在突发状况发生时，现场任何细微变动第一时间图传到指挥中心，并且指示无人机快速采取对应措施。奇蛙第一代云端飞行控制系统采用传统开源RPC框架开发，由于面临多客户端并发场景下带来的吞吐率下降和响应时间变长等问题，且随着业务发展

ServiceComb ServiceCenter 新的版本即将发布，在这次发版中将带来异构、多服务中心同步工具 Syncer，在这里将从我们的已有的实践经验出发，带来对Syncer的介绍。 项目地址： https://github.com/apache/servicecomb-service-center/tree/master/syncer 为什么使用服务中心同步工具 从传统架构到微服务，为了解决微服务之间动态变更带来的问题，各微服务框架百花齐放，从而衍生出Service-center、eureka、consul等一系列服务中心；在云环境大行其道的今天，公/私有云并存、混合云部署在企业实践中似乎已成为趋势。在这过程中不得不面临一些问题： 异构服务中心间的实例如何发现？ 跨区域间的实例信息怎么同步？ 统一企业内部微服务架构过程中，如何平滑迁移？ 中心化解决方案带来的思考 在最初的项目中，我们应用了ServiceCenter的中心化解决方案 ServiceCenter Aggregate，详细介绍请参考： https://github.com/apache/servicecomb-service-center/blob/master/docs/multidcs.md 。在使用这样的中心化解决方案后，异构服务中心的实例被同步到 Aggregate 中，服务只需指定服务发现地址到

关键字：网关，Zuul，Gateway，Spring Cloud, ServiceComb，Edge Service性能测试，微服务 作者 | 李昂 导读 本文对几种流行的 API 网关以关键指标 RPS 为依据，利用 wrk 做出性能测评并且给出结论。本文所有使用的软件、命令、以及代码均在文中注明，以便读者搭建本地环境进行测试。注意性能测试的数据在不同的运行环境中差别较大，但总体上来说各项数据会成比例变化，本文的测试过程和结论可以较准确地反应出各 API 网关之间的性能差异。 背景知识介绍 API 网关 近些年来，在云时代的背景下，为了适应互联网和大数据的高速发展，随着微服务架构的持续火热，对 API 网关的诉求越来越强烈，API 网关的产品也层出不穷。除了传统的 Zuul 和 SpringCloud Gateway, 还诞生了很多优秀的网关，本文选取了Edge Service 作为比较对象与传统的网关进行了 API 网关的性能测评。 究竟是久经沙场的老牌网关更经得起考验，还是新兴的网关性能更优？本文将给出详细的测评过程和结果。 Netflix Zuul Zuul 在这三个网关中是最早诞生的，其 github repo 早在 2013 年之前就已经存在，同年开始进入大众视野，崭露头角。虽然 Zuul 诞生较早，也占据着不小的市场份额，但由于 Zuul本身是基于阻塞io开发的

Edge Service是ServiceComb提供的JAVA网关服务。Edge Service作为整个微服务系统对外的接口，向最终用户提供服务，接入RESTful请求，转发给内部微服务。Edge Service以开发框架的形式提供，开发者可以非常简单的搭建一个Edge Service服务，通过简单的配置就可以定义路由转发规则。同时Edge Service支持强大的扩展能力，服务映射、请求解析、加密解密、鉴权等逻辑都可以通过扩展实现。 Edge Service本身也是一个微服务，需遵守所有微服务开发的规则。其本身可以部署为多实例，前端使用负载均衡装置进行负载分发；也可以部署为主备，直接接入用户请求。开发者可以根据Edge Service承载的逻辑和业务访问量、组网情况来规划。 开发微服务网关 搭建框架 使用ServiceComb的内置Edge Service边缘服务 3步完成搭建微服务网关 ↓↓↓ •配置依赖关系 在项目中加入edge-core的依赖，就可以启动Edge Service的功能。Edge Service在请求转发的时候，会经过处理链，因此还可以加入相关的处理链的模块的依赖，下面的实例增加的负载均衡的处理链，这个是必须的。 •定义启动类 和开发普通微服务一样，可以通过加载Spring的方式将服务拉起来。 •增加配置文件microservie.yaml Edge

在 微服务架构模式中后端服务的实例数一般是动态的，于客户端而言很难发现动态改变的服务实例的访问地址信息，服务网关能对用户提供统一的入口。 ServiceComb Java-Chassis 内置了网关服务EdgeService，开发者可以非常简单的搭建一个EdgeService服务。 具体可参考：https://docs.servicecomb.io/java-chassis/zh_CN/edge/by-servicecomb-sdk.html 本文将介绍ServiceComb与SpringCloud的Zuul网关组件协同工作，以构建微服务应用。ServiceComb在自身的处理链HandlerTrain中已完成Zuul的对接，用户用极简单的方法配置后即可使微服务应用具备网关服务的能力。 为使读者更好地理解，本文将编写一个简单的Hello微服务，并启动2个实例来进行演示。 Hello微服务提供hello/{name}接口，只需从前端输入参数name就可从后端微服务获取到程序员百看不厌的Hello world结果。 微服务模式下的Hello应用模型 技术准备 ServiceComb 作为后端微服务核心框架 ServiceCenter 作为服务发现与注册中心 SpringCloud Zuul 组件做服务网关 环境准备 以下环境为Windows 64位系统 ●安装git

在上两篇 [微服务]ServiceComb + SpringCloud Ribbon：使用篇 和 [微服务]ServiceComb + SpringCloud Ribbon：源码解读篇 中介绍了负载均衡的概念和ServiceComb结合SpringCloud Ribbon的使用, 本篇将介绍ServiceComb内置的负载均衡组件handler-loadbalance 本文参考于官方手册： https://docs.servicecomb.io/java-chassis/zh_CN/references-handlers/loadbalance.html 简介 ServiceComb提供了非常强大的负载均衡能力。它的核心包括两部分，第一部分是DiscoveryTree，通过将微服务实例根据接口兼容性、数据中心、实例状态等分组，DiscoveryFilter是其主要组成部分；第二部分是基于Ribbon的负载均衡方案，支持随机、顺序、基于响应时间的权值等多种负载均衡路由策略IRule，以及可以支持Invocation状态的ServerListFilterExt。 代码示例 以下代码请参考官方示例： https://github.com/apache/servicecomb-java-chassis/tree/master/samples/springmvc-sample

SeviceComb + Zipkin 简介 ServiceComb 是Apache的微服务顶级项目，在微服务框架中，微服务之间通过网络进行通信，我们必须处理所有与网络相关的问题，例如延迟，超时和分区。随着部署的微服务越来越多，我们需要系统监控微服务网络延迟和请求流。 上篇文章我们介绍了如何使用ServiceComb与Zipkin进行协同定位微服务应用的异常的微服务和具体异常函数。 本篇将介绍ServiceComb如何通过自身handler处理链机制支持Zipkin 微服务级别和函数级别的调用链追踪的。 ▼▼▼ ServiceComb 如何支持zipkin ServiceComb 提供了处理链机制，消费端和服务端的调用链请求都会经过该处理链，通过扩展handler处理链接口，可以实现负载均衡、熔断容错、流量控制等能力。同样，调用链追踪能力也是通过扩展该接口实现的。 关于ServiceComb处理链参考 ↓↓↓ https://docs.servicecomb.io/java-chassis/zh_CN/references-handlers/intruduction.html ServiceComb 扩展handler处理链接口，编写了handler-tracing-zipkin 模块。Handler-tracing-zipkin 模块在java-chassis

上一篇文章我们介绍了ServiceComb与SpringCloud的Zuul网关组件协同工作，以构建微服务应用。为了给ServiceComb做贡献的伙伴提供指引，本篇将介绍ServiceComb与SpringCloud Zuul的集成源码。 ServiceComb 对接 Spring Cloud Zuul 思路 ServiceComb没有修改SpringCloud Zuul的源代码，而是利用了 SpringCloud 提供的可扩展的接口。 Spring Cloud Zuul 官网有如下两段描述 ▼▼▼ •Zuul starter不包括服务发现客户端, 所以为了实现基于service ID的路由转发，你必须同时在类路径下提供一个服务发现客户端 （ 可以使用 Eureka ） •DiscoveryClientRouteLocator 过滤器从一个DiscoveryClient（例如Eureka）和属性文件中加载了路由定义信息。 详情参考：https://cloud.spring.io/spring-cloud-netflix/multi/multi__router_and_filter_zuul.html 从以上的描述看，SpringCloud Zuul允许我们自定义服务发现客户端来实现自己的服务发现逻辑。其中DiscoveryClient接口是Spring Cloud

分布式调用链追踪 能有效地监控服务间的网络延时并可视化微服务中的数据流转。ServiceComb扩展了zipkin的接口提供了服务内部的链路调用信息，能提供更完整的调用链路信息，更容易定位问题和潜在性能问题。 本文将介绍ServiceComb 提供的分布式调用链追踪能力及使用指导。 一. 异常场景示例 我们将使用ServiceComb的入门案例BMI（体质指数应用），展示ServiceComb的调用链追踪和自定义调用链追踪能力。BMI应用程序包含体质指数计算calculator和服务网关webapp两个服务。 参见ServiceComb的入门案例BMI指导 http://servicecomb.apache.org/cn/docs/quick-start/ 我们给BMI的体质计算服务增加了异常代码，如下。 参见BMI程序使用指导1 http://servicecomb.apache.org/cn/docs/quick-start/，运行bmi程序，出现如下异常结果。 二. 使用Zipkin定位服务级别异常 以上的BMI示例还未开启调用链追踪，下面我们将使用ServiceComb提供的分布式调用链追踪能力定位分析BMI应用的哪个服务发生了异常。 首先需要给BMI程序配置zipkin调用链追踪能力，只需添加两个配置即可。可参考分布式追踪2和Distributed Tracing