vlambda博客
学习文章列表

2018 年 10 月 24 日，Apache ServiceComb，一个以解决微服务问题为愿景的Apache基金会顶级项目进入大众的视野。近几年，微服务更多地暴露在国内技术圈的聚光灯下，成为技术社交、媒体和大会演讲的热点。两年前，华为云将 ServiceComb 开源并捐赠给 Apache 软件基金会，而在过去的两年，ServiceComb 社区每年都会出 1 篇周年文章。本文作为两周年的文章，带读者一起回顾微服务与 Apache ServiceComb的故事。

微服务和传统 SOA 同属于服务化架构体系，服务化架构需要追溯到 50 年前并且至今仍然发挥重要作用的「康威定律」。在 2000-2007 年，电子商务的快速发展促进了 SOA 的流行，互联网的爆炸式发展和普及引发了人们探索新一代服务化架构的热潮，最终促使了微服务的萌芽。

微服务从萌芽伊始，至今已发展 8 个年头，它是产业发展到一定阶段的产物，是 SOA 的一种进化。随着众多国内外企业对微服务的持续探索，世界级软件架构大师系统化地丰富和阐释概念、理论和实践相结合，共同勾勒出微服务的轮廓。

（图1 服务化架构的发展历程）

在产业发展趋势下，云原生、容器化技术日臻完善，基础设施自动化、持续交付、按需虚拟化、小型自治团队、大型集群系统等实践纷纷流行，为微服务的落地提供了良好的土壤，微服务在协同云化应用快速创新、按需弹性伸缩、短平快持续交付等方面将发挥越来越积极的作用。2016 年开始，微服务成为仅次于物联网和认知计算的第三热门软件架构，在 Gartner 的 Hype Cycle 技术成熟度曲线上排名非常靠前，Gartner 认为微服务在未来 2~5 年内成为主流。

随着云化和互联网技术的发展，企业 IT 部门从原来的成本中心转变成生产中心，如何将客户需求和软件价值更快地交付到客户手中成为企业的核心竞争力之一。可以说，以前是大鱼吃小鱼，现在是快鱼吃慢鱼。

现代软件应用的领域越来越广，无论是工作、生活还是娱乐，应用（特别是消费类应用）流量会出现明显的波峰波谷。例如，游戏一般在工作日和白天玩得少，而在休息日和晚上玩得多。还有些无法预期流量的应用，可能大部分时间流量一直稳定，而一个意外事件的发生就会导致流量产生指数级增长。无论是哪一种场景，都要求应用架构能具备更好的弹性能力来保证业务的可用性。

经过这一波互联网技术洗礼之后，行业边界正变得越来越模糊，很多企业特别是传统行业都希望通过业务创新获取新的增长点，而业务创新九死一生，从 IT 部门视角来看，基于团队已有的技能，重用企业已有的技术资产（比如投资了很贵的技术平台软件），这就是节省成本。

从程序员的角度来看，不同行业不同领域都有不同技术栈。例如，开发语言没有绝对的好坏， Java、C++、Python、Golang 等都有其适合的场景，多数企业的技术决策者希望用合适的技术去匹配业务，所以在选择能支撑未来业务持续发展的基础性框架和平台产品时，对技术本身开放性的考量也是至关重要的。

从企业用户的视角来看，他们的诉求往往是：高可用性、容错性、可管理性、可替代性、可测试性、组织扩张、架构弹性等。其实从这些反馈不难看出，业界对微服务的诉求不仅仅是需要某个单点问题或一个工具套件，而更多的是希望通过微服务这种新的研发理念来改变整个研发活动的方方面面，包括技术、组织和流程的变革。

基于以上，我们可以从业务视角总结出微服务的本质价值：

• 更快：是指业务上线的速度，使用微服务能把业务上线周期从年降到月、周，甚至是随时上线；

• 更稳：是指系统可用性，基于微服务构建的系统能把系统 SLA 从 3 个 9 提升到 4 个 9、5 个 9，甚至永不断服；

• 更经济：是指业务的资源成本，基于微服务更细粒度的弹性，能实现业务规模扩张与资源支出的最佳平衡。

（图 2 微服务的本质诉求）

企业应用微服务化，是为了满足业务快速上线、短平快交付和按需弹性三方面的本质诉求。然而，它却不是万能钥匙，同样会引入诸多问题。

• 如何基于微服务架构高效开发和上线？

传统的单体应用因为是单进程，组件 A 与组件 B 的进程内调用只需使用少量的代码就能搞定，但是在微服务系统里，存在服务发现、服务容错、服务限流、服务降级、分布式事务等诸多复杂的分布式技术问题。如果我们把这些问题都留给业务开发人员，显然业务开发是快不起来的，这就是微服务化之后面临的第一个问题。

• 如何在不可预期的流量下保证业务的高可靠运行？

从一个单体应用拆分成多个独立运行的微服务应用，从理论上来说，系统的故障点是增多的，用户请求的每一跳都有可能出错，特别是在资源受限的大规模流量冲击下，这一问题会更加突出，这又引入微服务化后的第二个问题。

• 在复杂的微服务系统中如何实现问题快速定位与恢复？

在微服务系统中，特别是在动辄上百个微服务和实例部署的场景下，一个业务请求很可能跨越了多个微服务多个实例多个节点，别说定位问题，就是先搞定问题定界都很难，这时候如果没有一个自动化的工具或平台来支撑，是单纯靠人力不可能完成的任务。

• 传统架构下的遗留系统如何向微服务架构低成本迁移？

最后是一个非常现实的问题，特别是在传统企业里面，都会有一些遗留的资产或运行中的业务系统，不可能把这些都推倒重来，不仅成本太高，而且业务风险也大。如何将传统架构下的遗留系统低成本的向微服务架构迁移，或者遗留系统与新兴的微服务业务系统进行通信，也是微服务解决方案需要系统考虑的。

（图 3 Apache ServiceComb 为微服务化痛点而生）

Apache ServiceComb 最原始的两个子项目，微服务 Java SDK servicecomb-java-chassis 和服务注册与发现中心 servicecomb-service-center，都源自于华为云微服务应用平台 ServiceStage。   

讲 Apache ServiceComb 的诞生，不得不提华为云。华为公司从 2012 年开始在很多创新项目里应用微服务技术，在 2014 年随着微服务框架技术愈加成熟，工具愈加完善，各个产品线开始基于微服务框架做云化产品。2016 年，华为公司为促进能力共享，将散落在各产品线的微服务相关的工具、平台、框架和团队统一整合成华为公司级华为云微服务平台的重要组成部分，专门负责微服务平台的交付和技术演进，统一支撑整个华为公司产品微服务化转型。

2017 年随着华为云的成立，华为云将能力在公有云上开放出来，同时开源了 ServiceComb 微服务项目，期望与开发者共同创新解决问题，也想让业界更多的企业和开发者避免走华为原来走过的弯路，同时，考虑到让社区更加中立和多元化发展，将 ServiceComb 捐赠给了 Apache 软件基金会。

（图 4 Apache ServiceComb 发展路线）

Apache ServiceComb 发展到今天，实际上是一个项目群，在 Github 上共拥有 7 个主要的子项目，其中已成熟的项目为微服务 Java 语言 SDK servicecomb-java-chassis 和微服务注册与服务中心 servicecomb-service-center。每一个子项目展开都是一个深度的课题，以下简要地介绍一下各个子项目。

• servicecomb-java-chassis

一个开箱即用的 Java 微服务 SDK，含服务契约、编程模型、运行模型和通信模型 4 个部分，具备负载均衡、容错熔断、限流降级、调用链追踪等全面微服务治理能力，拥有服务治理能力与业务逻辑隔离使能自动具备基本治理能力、纯异步内核使能高性能、内置契约能力使能代码自动生成契约等优点。

成熟项目，社区已发布了 11 个版本，稳定在各企业各样的商用业务中运行。

• servicecomb-service-center

基于 Etcd 的高性能、高可用、无状态的 Golang 版分布式服务注册与发现中心，可实时服务实例注册、实时服务实例推送和服务间契约测试等，支持不同的服务中心之间异构通信。

成熟项目，社区已发布了 12 个版本，稳定在各企业各样的商用业务中运行。

• servicecomb-pack

由 Saga 更名而来，在通用的集中式事务协调平台基础上为用户提供 Saga 和 TCC 分布式事务协调机制，保证事务最终一致性。值得一提的是，Saga 的理论来源于 1987 年的一篇论文，现在的 pack 是在开源社区从零开始孵化的，集来自华为、京东数科、红帽、亿阳信通等企业的个人贡献者的智慧而成，这些贡献者也已悉数被选举成为 Apache Committer。

• servicecomb-mesher

一个生产级的服务网格 sidecar 实现。Mesher 实际上在华为内部 2015 年就已进入商用实践，在 2018 年 6 月份开源到 Github 上。鉴于 Mesher 的生产实践和多语言能力，近期 Apache ServiceComb 的 PMC（由活跃贡献者组成的社区管理委员会）通过投票将其纳入到了 Apache ServiceComb 的范围。Mesher 可以和 ServiceComb、Istio 和 Zipkin 等控制面板协同工作，可以同时部署在 K8s、Bare Mental 和 VM 等多种基础设施上，可以基于微服务元数据的进行路由管理和多协议支持。

• servicecomb-toolkit

一键式契约管理服务，提供契约、代码、文档相互转换及校验的能力，支持快速构建基于流行微服务框架和流行编程模型的微服务工程，使用户聚焦业务开发，同时支持 ServiceComb SDK 和 SpringCloud SDK。

这是社区技术专家在帮助微服务企业微服务化过程中面对痛点创新孵化中的子项目，在两个场景下 toolkit 会非常有用：在集成多厂商应用的企业中，可以使用它来统一定义接口描述标准，使用工具套件一键生成基于指定微服务框架的微服务工程，并且通过服务契约校验手段协同维护整体系统的一致性，以此协调多个开发团队。在遗留系统微服务化中，可以使用 toolkit 分析遗留应用提取服务契约，再一键生成基于指定微服务框架的微服务工程，使开发者聚焦业务开发，减少用户对微服务框架的学习成本。

• servicecomb-kie 

一个语义型的配置中心，解决在生产环境中常规配置中心的键的语义学习成本高、管理成本高、拼接复杂和无法扩展等实际问题。  

这是面向为了解决生产级别的实际服务配置问题而在孵化中的子项目，在其规划中，配置中心未来会同时支持 Console、K8s 等基础设施的配置。

• servicecomb-fence  

支持 OAuth 2 和 OpenID Connect 协议，在认证鉴权维度，提供不同的架构模式解决性能和安全问题，支持不同的接入场景和访问控制策略。   

系统内部的认证鉴权和第三方认证接入，是阻塞开发者开发效率的关键因素之一，也是许多开发者容易疏忽造成安全问题的地方。这个孵化项目旨在从系统架构和开发者维度去帮助保证分布式认证的安全性和高效性。

（图 5 Apache ServiceComb 全景）

除此之外，Apache ServiceComb 还维护了像社区 docs、社区 samples、社区官网等子项目，这些都是作为一个开源社区的必备的资源。同时，Apache ServiceComb 力求跟业界的流行生态项目进行融合，以开放的心态要求自己，把自己能做好的做好，把开源社区其他项目擅长的优势吸纳进来。

亚马逊飞轮逻辑：“一旦核心部分各就各位，飞轮被激活，飞轮就会随着时间产生持续的动力并变得更强。”企业、开源社区、开发者，三者之间形成一环扣一环的齿轮，当这些齿轮一起发生作用的时候，自然会形成飞轮效应。

（图 6 开源社区的 3 个飞轮）

Apache ServiceComb 最初开源出来的时候，仅仅只拥有 java-chassis 和 service-center 两个子项目，如今发展到 7 个子项目，这些驱动力来自于企业用户和开发者，这些都是来自于实践过程中共同发现的难题而促成的孵化。

华为云捐赠 Apache ServiceComb 以后，并没有将其视为一锤子买卖，华为也一直投入了来自华为云和华为开源软件能力中心的技术专家在其中，并且基于 Apache ServiceComb 提供华为云 ServiceStage 商业云服务。站在 Apache ServiceComb 社区的维度，感谢华为这位 Sponsor。

当前在 Apache ServiceComb 开源社区和社区 PMC 里面，拥有来自各企业的个人的贡献者，但不可否认，主力贡献还是来自华为。作为一个 Apache 开源社区，非常期望其他的企业也可以踊跃参与到社区贡献中，当我们谈到 Apache ServiceComb 的时候，可以说这个社区主要由 A+B+C 企业贡献。目前我们已经欣喜地见到，有许多个人贡献者在 Apache ServiceComb 的社区群里回答用户问题，主动写文章进行分享，这些都让社区的成员兴奋不已。

“宁可演讲无数，不可错过一名开源人士“，这是开源布道圈里面流行的一句话，每一个用户 / 开发者，都是开源社区宝贵的财富。

著名投资人查理. 芒格说：“如果一个人手里只有锤子作为武器，那么他解决所有问题的方式就是只会使用锤子“。Apache ServiceComb 社区的愿景是：致力于帮助企业、用户和开发者将企业应用轻松微服务化上云，并实现对微服务应用的高效运维管理。但是社区同样拒绝拿着“微服务”的锤子到处去找钉子，真正的钉子是由企业用户去发现的，由个人开发者去发现的。所以，Apache ServiceComb 社区从来没有想去画一个美丽的长远版图，而是在与用户和开发者的实践中不断去成长。

2017 年，ServiceComb 由华为云开源并捐赠给 Apache 软件基金会，华为云继续基于 ServiceComb 在微服务应用平台 ServiceStage 上提供商业云服务，并持续投入与创新，作为社区开发主力在 Apache 软件基金会指导下进行 Apache ServiceComb 的孵化。

2018 年 3 月，ServiceComb 获得《OSCAR 尖峰开源技术创新奖》；

2018 年 10 月，Apache ServiceComb 毕业成为业界首个 Apache 微服务顶级项目；

2018 年 12 月，在 2018 年 12 月 Apache ServiceComb 获得《COSCL 首届优秀中国开源项目一等奖》；

2019 年 4 月，Apache ServiceComb 成为业界首个微服务行业标准的核心参考框架；

2019 年 4 月，基于 Apache ServiceComb 提供商业云服务的华为云应用平台 ServiceStage 作为业界微服务平台典型代表，以其完整的解决方案和成熟的产品能力获得评估专家团队的一致肯定，顺利通过可信云微服务标准评估；

2019 年 7 月，信通院《2019 开源产业白皮书》中披露了 Apache ServiceComb 在微服务领域表现突出，无已知安全漏洞，无许可证传染性，企业和用户可以放心使用。

在未来，Apache ServiceComb 社区将继续保持兢兢业业，认真听取来自用户及开发者的诉求和建议，让Apache ServiceComb 社区常青。

（图 7 Apache ServiceComb 社区召集令]   ）

在文末，特别想感谢，由于 Apache ServiceComb 未进行企业用户统计，在这里只能不具名地感谢支持的社区的企业用户们。对于开发者，这里有一个不完全的开发团队名单：

http://servicecomb.apache.org/cn/developers/team/ 。感谢大家的厚爱！感谢 Apache 软件基金会提供了孕育 Apache ServiceComb 的土壤和环境。

可用性和监督：

Apache ServiceComb 软件是在 Apache License v2.0 下发布的，由活跃贡献者组成的管理委员会（PMC）负责指导项目的日常运营，包括社区发展，产品发布和制定技术路线图。有关下载，文档以及参与 Apache ServiceComb 的方法，请访问：

https://github.com/apache?q=servicecomb

http://servicecomb.apache.org/ 

https://twitter.com/ServiceComb。

[1] Apache ServiceComb 开源一周年文章：认真做开源，扎实做微服务

[2] Apache 软件基金会通告 Apache ServiceComb 毕业成为顶级项目https://blogs.apache.org/foundation/entry/the-apache-software-foundation-announces41

[3] 如何加入 Apache ServiceComb 社区http://servicecomb.apache.org/cn/docs/join_the_community/

在此感谢刘云华、马彬、姜宁、田晓亮、刘宝等提供部分内容素材。