Apache ServiceComb开源一周年回顾

18年6月25日，开源界盛会LC3（LinuxCon + ContainerCon + CloudOpen）在北京拉开帷幕，一年前，同样在LC3大会上，ServiceComb由华为云微服务引擎服务开源，ServiceComb和蜂巢Logo一起正式走入开源和微服务领域。

回望过去，ServiceComb于17年12月由华为云捐赠给了Apache软件基金会，成为国内第一个进入Apache孵化的微服务项目，累计贡献给Apache社区33万多行代码，发布1.0.0-m1和1.0.0-m2共6个孵化器软件版本，使用用户覆盖到了IoT、生物医药、金融、互联网、地产、AI等行业。

在这里，尊重、诚实、专注、透明决策、开放……，社区日渐活跃和健康，正稳步践行“Apache Way”。细细盘点过去一年，我们发现，ServiceComb正在一步一个脚印实现着社区伙伴们对于微服务的坚持——“通过微服务解决方案解放用户和开发者”。

ServiceComb从哪里来

ServiceComb 源自华为云微服务引擎，主体代码由华为云捐赠，致力于帮助企业轻松构建云原生应用及传统企业业务快速微服务化，通过系列解决方案帮助用户快速开发微服务的同时实现对这些微服务应用的高效运维管理。华为云微服务引擎在华为内部系统商用了3年多时间，通过“吃自己的狗粮”的方式在保持电信行业高性能低时延能力的同时也历经了华为VMALL商城等电商场景的历练。

例如，华为消费者云业务拥有数亿级用户访问量，业务对性能和时延等要求都非常高，曾尝试使用其他分布式框架实现，由于大部分业务是I/O密集型的，同步微服务调用模式导致CPU利用率低，性能也无法提升，硬件资源利用率低。采用ServiceComb的Reactive全异步模式之后，QPS提升2倍+、时延降低45%，大量的硬件资源因此被节省，并异步模式同时解决了传统分布式框架经常遇到的雪崩效应，即某个微服务调用慢导致上游调用方被阻塞引起雪崩。可以说，在诞生伊始，ServiceComb就把高性能放在了首要位置进行设计开发。

高性能的微服务框架 

近几年的发展，微服务逐渐普及，并且开始应用于云上业务的核心组件。这就要求微服务框架能够在这种场景下，保证系统的资源占用、时延等性能指标能够满足业务系统的需求，而业务线程利用率低，超时时间配置过长导致成功率低和雪崩效应是微服务化中的最严峻问题，故当前开源领域的微服务或分布式框架都正在竞相尽全力支持异步内核中。

高性能

ServiceComb在设计之初就将Vertx作为异步调用的内核，实现同异步可选。当业务代码也使用异步模型时，业务逻辑直接在Eventloop中执行，整个业务流程中没有线程切换，所有的等待逻辑都是异步的，只要有任务，则不会让线程停下来，充分、有效地利用系统资源并提高系统吞吐能力。

全异步内核之异步调用

在电商、互联网、IoT等新兴领域中，长流程或复杂业务流程是很常见的，这就造成了一个消费端需要调用多个微服务进行业务逻辑编排或者多个微服务进行级联的场景。

另外一种的类型，业务本身对服务调用的时延不敏感，传统的手段是采取同步调用并设置大的超时时间来处理，这种实现方法将会导致在业务高峰期时延达到超时阀值时系统被轻易压垮。

ServiceComb的异步内核特点在以上场景的实际业务中都发挥了充分的价值，在电商和IoT两个实际业务中TPS提升约50%，CPU占用率下降50%，时延降低约30%，这将意味着ServiceComb帮助用户节约近一半的硬件资源，也有效防止了微服务领域最易面临的雪崩效应。

全异步内核之同步调用

在业务使用同步模型时（既存系统改造等场景），ServiceComb进行了多项优化以减少系统各组件的阻塞。

1. 在微服务进程中，为传输层创建独立的Vertx实例。
2. 为每个连接额外配备一个CAS消息队列，将所有消息保存到CAS队列中，减少入队竞争。通过原子变量判定，只有入队前CAS队列为空，才向Eventloop下发写任务，唤醒Eventloop线程。
3. 允许通过配置，在服务提供者和消费者之间建立多条连接，充分利用硬件资源。
4. 在服务提供者端，支持隔离仓技术，实现故障隔离。为不同的业务进分组，并配置不同的线程池，解决不同处理速度的业务逻辑在同一个线程池中造成的业务整体性能下降问题。支持在进程、接口、方法三个级别进行线程池配置。

在第三方个人的评估报告中，ServiceComb的同步服务调用在当前主流的微服务和分布式框架中性能排在前列。

一站式开箱即用微服务解决方案

PaaS先驱Heroku公司的CTO Adam Wiggins 为实现软件即服务提出微服务12要素，以从软件设计、开发到运维的整体端到端角度思考程序的架构演进。

一直严格遵循微服务原则

在ServiceComb前身华为云微服务引擎出现之前，公司也有部分业务和众多企业一样，尝试了各样云原生微服务化方案，时至今日，我们也依旧可以在网络上见到众多如“A+B+C实现微服务框架”的文章，也见到各类开源RPC框架正在紧锣密鼓支持微服务化中。

ServiceComb，一站式的微服务解决方案，其前身华为微服务引擎的设计就已经严格遵循微服务原则，开源之后更是坚持力求在设计、开发、运维方面都给用户及开发者以最佳的体验，同样投入下获取更多的产出。

ServiceComb提供包括JAXRS、SpringMVC和透明RPC在内的多样化的编程风格。使得程序员在使用微服务框架时能够保持自己的习惯。

OpenAPI

OpenAPI吸收了大量的跨语言经验，可在不同语言之间进行解析。ServiceComb围绕OpenAPI开源生态和Swagger工具，以服务化契约为中心构建，可通过编写代码或编写接口实现契约，契约先行支持自动生成代码，自动生成接口文档，自动生成测试桩代码和挡板程序等。ServiceComb同时支持REST协议和二进制私有Highway通信协议，且可通过修改配置文件和注解的方式轻松的切换，在构建业务系统时，可以根据需要和测试结果，进行灵活的选择。ServiceComb的治理结构也围绕服务化契约构建，基于ServiceComb及ServiceComb支持的工具，业务可在设计和开发阶段保持开发者习惯的前提下轻松实现微服务自治及松耦合。

ServiceComb内置

ServiceComb内置轻量级高性能边缘服务，支持Producer端治理，结合扩展路由能力和动态配置能力能轻松实现灰度发布、A/B测试等关键特性，在业务实测中，在同等资源使用下吞吐能力是业界常规方案的2.8倍。

ServiceComb内置覆盖了微服务下绝大多数场景的流量控制、容错熔断、限流降级、故障注入等治理和管控能力。内置支持包括RoundRobin、Random、WeightedResponseTime、SessionStickiness在内的丰富的负载均衡策略，与服务中心ServiceCenter配合，实时感知微服务实例的状态变化，灵敏调节负载。

APM

APM在微服务领域用于帮助理解系统行为、用于分析性能问题。ServiceComb从Metrics、Tracing和Log三方面全面支持APM，内置的Metrics包含基本资源使用、调用次数、时延和TPS等关键指标，支持HttpCode、Consumer/Producer等丰富的维度用于数据二次聚合；Tracing无缝对接主流的Zipkin和新兴的SkyWalking；微服务运行的关键信息也将无需用户配置自动写入日志。动态配置、优雅停机、事件通知等机制也被ServiceComb优雅内置。

一站式开箱即用

如果把开发一个微服务应用比作买房的话，传统的微服务或分布式框架提供的是“毛坯房”，从收房到入住还要经历辛苦的装修过程。而ServiceComb提供的则是“精装修房”，不求覆盖最全，只求配合最好，体验最舒适，让用户或开发者能够“拎包入住”。

例如创建一个CRM应用，真实业务下会设计拆分出十几个甚至更多的微服务，为了让这些微服务能够很好地在一起工作，通常需要用户逐个学习对应所需组件、添加依赖、分别进行配置，选择哪些组件?怎么用?如何添加依赖？裁剪时依赖对应哪些功能？版本之间是什么关系？版本冲突如何解决？诸如此类一系列的问题都会让开发者特别是初学者头痛不已。

相比而言，ServiceComb java-chassis-dependencies集中管理了所有必须的依赖，start.servicecomb.io生成出来的项目既包含示例代码，也包含必要配置的以及微服务治理所需的配置，批量生成所有的微服务后，用户只需要专注于填充业务代码。完成开发后，部署ServiceCenter，启动微服务，一个良好的CRM系统就运转起来了，之后只需要专注于运维，后期也可通过动态配置，随时修改配置值调整治理能力。在整个过程中，ServiceComb坚持“约定大于配置、集中配置”，一切化繁为简，拒绝凌乱。使用ServiceComb可以在30分钟内开发出一个雏形的CRM应用。

ServiceComb一站式开箱即用，严格遵守微服务原则，伙伴用户软通动力使用ServiceComb从设计维度解决业务交互复杂引入的代码重复度高和大型应用部署困难等阵痛，新型创业公司奇蛙无人机更是能够一天之内从传统分布式框架迁移到ServiceComb。

ServiecComb并没有为了减轻用户和开发者负担而封锁自己的设计，那样将无异于让用户住进了牢房，虽然衣来伸手饭来张口却没有了自由，而是为了让业务能够定制化自己的特别需要、方案长足发展和吸收如SpringCloud等优秀组件的精华，ServiceComb坚持了开放性设计，消费者和生产者编程模型可扩展，通过治理链可扩展治理能力，通信协议可扩展，并可开放对接到其他的注册服务、配置服务等三方组件，可既轻量级运行于Netty Http之上，也可作为一个Servlet运行于Web容器里。

协同开源力量攻克微服务难题

在微服务架构下，应用通常是由一组松耦合的相互协调的服务所组成，每个服务独立使用自己的数据库。在缺少一个统一的数据库来提供事务一致性的前提下，如何协调各服务之间的分布式事务，是微服务化的过程中所面临的一大难题。ServiceComb提供了Saga子项目，在理论指导下，正协同社区力量在不断研究好的方法和实践来解决这个难题。

Saga

Saga来源于数据库处理长时事务一致性处理论文， 一个长时事务是又多个本地务组成，每个本地事务提供了执行以及执行失败补偿两个方法。

Saga通过协调系列本地事务执行（事务执行失败会调用相关补偿方法来恢复原有状态），来证长时事务执行的一致性。与现在主流的TCC模式相比，ServiceComb saga对业务逻辑侵入小，且性能更高。在过去的一年中，ServiceComb Saga完成了从“集中式”到“分布式结合集中式的”演进，支持了通过注解标注Saga对应子事务信息。未来，ServiceComb saga将在多租户服务支持、消息队列传递事件信息等方面继续提升，朝着“更好用、更高效”的方向努力。

ServiceComb要到哪里去？

ServiceComb已开源一周年，越来越多的中国企业也陆续开源了其自研的分布式或微服务框架。ServiceComb试图努力将全球最大的开源社区的精髓Apache Way带入了中国企业的微服务领域，给开源开发者和企业用户提供了更加亲和的土壤。

未来已来

2018是服务网格元年，Service Mesh的出现，与ServiceComb致力于解放用户和开发者的愿景相匹配， ServiceComb一直在思考如何将Service Mesh理念更好地运用到微服务解决方案之中，当前已经有了一些雏形思路。喜讯是华为云作为最早将Service Mesh产品化商用的企业之一，计划于7月份开源名称为Mesher的的高性能服务网格部件，旨在将微服务中的应用问题和网络问题分离，继续为微服务开源的发展贡献自己的力量。ServiceComb未来会继续以完全开放的态度在服务网格技术维度和相应主流社区保持兼容，吸纳侵入式和非侵入式方案，作为完整的微服务解决方案在开源爱好者们和微服务从业者们的支持下散发光和热，也期待社区志愿者们和ServiceComb一道贡献智慧。

致谢  

过去的一年，众多开源爱好者和微服务从业者们对ServiceComb给予了大力关注和支持，截至今日，大量开发者和用户向社区项目提交了代码、贡献了智慧、力量。以下致谢：

Roman Shaposhnik 等13名正式committer，Feng Zheng 等25名正式contributor，其他未在社区网站具名的支持者，包括但不限于：

• Apache社区的支持；
• 已经向社区项目提交代码的大量开发者；
• SpringCloud、Skywalking等开源微服务领域项目的支持协同；
• InfoQ、开源社、CSDN、开源中国 等社区和媒体的支持等；
• 华为消费者云、云EI、云安全、云核，软通动力，文思海辉，互灵物联，奇蛙无人机，梅斯医药，杭岭科技，高迈致远等一批伙伴用户的支持。

开源的力量是无穷的，ServiceComb的点点滴滴前进来自方方面面支持，感谢开源志愿者们的一如既往，才有了ServiceComb社区的踏实前进。

参考资料

[1] 如何设计一个优质的微服务框架 刘宝  

http://servicecomb.incubator.apache.org/cn/docs/open-design/

[2] Saga分布式事务解决方案与实践 姜宁

http://servicecomb.incubator.apache.org/cn/docs/distributed-transactions-saga-implementation/

[3] RPC Benchmark Round 3鲁小憨

https://www.jianshu.com/p/caf51f5cfbaa

[4] ServiceComb开发团队

http://servicecomb.incubator.apache.org/cn/developers/team/