Apache 主席话开源之道，ServiceComb 微服务创新实践解放开发者

Apache ServiceComb 项目成立已经 2 周年，一路以来，社区遵循 Apache Way，坚持中立、开放、多样化的原则，携手用户和开发者长足健康发展。

2019 年，在认真听取社区声音后，社区推出 5 大创新新品项目，期望与用户和开发者一起思考如何共同去解决微服务中的难题，为更好地回馈社区用户和开发者，在 Apache 软件基金会成立 20 周年之际，Apache ServiceComb 在 HC2019 华为全联接大会会场举办了“Apache 开源开发详解”和“微服务创新实践解放开发者”社区活动。本文回顾了此次活动中嘉宾的精彩分享内容，以及用户和开发者聚焦的典型问题。

Apache 软件基金会董事会主席 Craig Russell、Apache 孵化器管理委员会主席 Justin Mclean 两位重磅嘉宾出席了此次活动，并为中国的开源爱好者独家剖析 Apache 的开源开发之道，对国内开源开发者、在校同学在实践中遇到的困惑给出了独到的见解和建议。

同时，来自华为的 Apache ServiceComb VP 姜宁、Apache ServiceComb 架构师马彬、华为云 ServiceStage 架构师王启军为大家分享了 ServiceComb 进入 Apache 的成长之路和趟过的那些坑、ServiceComb 面向用户痛点创新的 5 个项目解读、华为云 ServiceStage 在微服务自动化拆分工具的创新实践，并对开发者关心的遗留应用向微服务转型如何拆分数据库/表、如何降低对底层开发框架的学习门槛快速实现微服务改造和开发、多厂商集成过程中可能出现的异构服务如何互通，以及多语言如何实现微服务转型等问题做了开放式的探讨。

Apache 软件基金会董事会主席 Craig Russell 话开源之道

Apache 之所以能够受到世界上众多开源开发者的青睐，并且长盛不衰的原因是什么呢？Apache 软件基金会董事会主席 Craig Russell 结合 Apache 的使命和 Apache 之道诠释：

• Apache 是公益性组织，坚持“为公众利益提供免费的软件”的使命，使用商业友好的 Apache 协议，让整个世界的公众从中获益，并乐于接受所有人的捐赠。

• Apache 保持中立，不受任何企业或个人控制，注重构建社区并且为这些社区提供项目管理服务，是“一个基于协作，一个基于交流和共同打造伟大的软件的地方”。

• Apache 提供了对社区项目的治理之道 Apache Way，它让社区和人们可以携手走在一起，来追求一个共同的目标，其核心理念是“社区胜于代码”，社区的位置放在首位，没有独裁者，由社区来决定什么才是正确的事情，并且每个人都可以通过参与社区贡献并获得功绩。

Craig Russell 表示：Apache 为众多开源爱好者提供了广阔的舞台，中国作为亚洲使用 Apache 软件最活跃的国家，越来越多的公司或个人项目加入到 Apache 回馈社区，社区也在积极地回馈每一位贡献者：免费的培训和学习平台，打造高质量的代码，合作与竞争的共赢平衡，并且使所有贡献者受到法律保护。

Apache 软件基金会孵化器主席 Justin Mclean 谈成长为 Apache 顶级项目之道

在认识 Apache 之后，项目如何进入 Apache 孵化器发展，并最终毕业成长为世界顶级项目呢？Apache 软件基金会孵化器主席 Justin Mclean 结合丰富的管理和实践经验，给出了非常中肯的建议：

• 围绕项目建立社区，活跃的社区“可以自我纠正，应对各种挑战和问题”，社区沟通的原则倡导友善、尊重、信任和谦虚，Justin 表示：“我们要信任，要假设其他人都是有善意的”。

• 许可协议非常关键，它保障用户使用软件时不出现任何纠纷，同时也保护社区的商标、项目名字不被别人仿照，是合规性重要的一环，也是成为顶级项目的必要条件。

• 发布版本，为了提供法律保护和发展社区，发布的流程需要确保符合 Apache 的流程和规定，并且必须由 PMC 投票。

• 项目毕业，当一个项目具备自管理、独立发布的运作能力，并遵从 Apache 软件基金会的规则，建立好法律框架，不再需要孵化器组织或者导师的帮助，即满足从 Apache 孵化器毕业成为顶级项目的条件。

• 

Apache ServiceComb VP 聊项目成长之路和趟过的那些坑

作为 Apache Member、Apache ServiceComb 首席技术专家，姜宁老师也曾担任过 Apache RocketMQ 项目孵化阶段的导师，有丰富的实战经验，姜宁老师为大家分享了 ServiceComb 如何从零开始，并在 1 年内成长为首个 Apache 微服务顶级项目的经验：

• 与 Apache 导师保持充分交流非常重要，在导师丰富经验的帮助下，可以更快速地了解和适应 Apache 规则和流程。

• 充分利用好 Apache 邮件列表、JIRA 等公共的沟通渠道，让更多的参与者了解项目、社区构建以及未来的规划，邮件列表归档的功能也能使刚进入社区的贡献者能快速找到每个事情的上下文，融入社区。

• 项目捐赠给 Apache 之后，名字和商标不能在商业产品里面随便乱用。

• 定期举行线上线下活动，为社区的参与者和开源爱好者提供互相交流的平台，有利于促进与其他社区、项目之间的合作和推广。

• 鼓励大家参与，为社区贡献者留下适当的发挥空间，建立“帮扶”机制，让更多的人能够参与进来，壮大社区。

• 抱着善意的心态去对待投票-1，因为每个-1 意见都包含着参与者对社区的付出，并且从每次-1 票中找出问题并改进。

• -务必确保项目的每行代码的来源是清楚的，没有 copy right 和 license 的使用问题，这也是每次版本发布前需要重点检查的地方。

• 

Apache ServiceComb 架构师解读面向用户微服务痛点的创新项目

众所周知，微服务是一种架构理念，软件架构极大依赖于专家经验，而专家经验更多地是依赖口口相传或者文档传播，在企业向微服务转型过程中，有没有相应的软件或工具能够解放专家手脚、帮助开发者快速上手成为用户的关键痛点。

ServiceComb 进入 Apache 以来，认真听取社区声音，确定了系列解决用户微服务化过程中痛点的方向，并且在社区里面继续创新孵化，于 2019 年推出 5 大新品项目解决微服务痛点问题，Apache ServiceComb 架构师马彬解读了 5 个新品项目面向的场景、现状和下一步开发计划：

• servicecomb-mesher，高性能服务网格框架，开箱即用、多语言、零侵入业务代码实现微服务化改造。

越来越多的企业开始向微服务架构转型，不同的企业使用的语言不同，甚至同一个企业由于业务差异、联合创新等因素，都有可能涉及使用不同的语言，而传统的微服务开发框架具有业务侵入性特征，无法满足多语言场景、异构框架的服务治理互通诉求。

servicecomb-mesher 支持以 sidecar 的形态无业务侵入解决用户在多语言场景下的痛点问题，并且其始终遵循开放式的设计，支持接入云原生、运维、监控等流行生态，未来将在网关/生态/异构支撑等方面继续探索，帮助用户以最小化改造完成微服务转型。

• servicecomb-toolkit，一键式微服务开发工具，自动化生成微服务工程、API、代码、文档，并支持 API 与代码一致性校验能力。

在集团型企业中，集成多个开发商应用的场景很常见，然而，不同的开发商存在开发语言、框架、习惯方面的差异，导致数据、服务标准不统一。

servicecomb-toolkit 帮助用户快速构建基于 ServiceComb 和 SpringMVC/Jax-RS/RPC 等编程模型的微服务脚手架，提升遗留系统重构、全新微服务开发的效率，协同用户实现基于标准 API 数据、服务标准化管控。未来 servicecomb-toolkit 将在支持一键制作基于 Spring Cloud 的微服务脚手架、OAI V3 规范、以插件集成到流行 IDE 方面做进一步的探索。

• servicecomb-service-center/syncer，对用户透明的数据同步工具，使能异构、多服务中心数据互通。

多数据中心部署的企业，不同数据中心之间的服务数据如何互通？集成不同开发商的集团型企业，异构微服务开发框架实现的微服务如何互通？这些问题在传统企业做微服务化选型或改造过程中经常被提及。

ServiceComb syncer 为此场景而设计，它提供数据同步能力，对用户透明，对多服务中心提供对等网络，并支持异构服务中心的数据转换和同步，使基于不同微服务技术栈实现的业务可以进行数据通信。未来，syncer 将对跨云、跨数据中心等场景提供更完善的支持。

• servicecomb-kie，语义型分布式系统配置中心，使运维人员通过易于理解的数据和入口，管理复杂的分布式系统配置。

传统的配置中心，多使用 key:value 数据模型（如：ServiceB.user.getUser.timeout=10s），key 的规则只在该服务内生效，对于运维人员来说难以理解。而且随着规则定义的不断增长，key 也会越来越复杂，对用户呈现也只有 key/value 单一视图，影响了可读性且不易于管理。

servicecomb-kie 通过支持 key(label):value 的数据模型设计改进了用户配置方式（如：Timeout(service=serviceB, schema=user, operation=getUser)：10s），通过 key 和 label 的组合提升了用户可读性，方便扩展变更，并且支持生成多角度的配置视图。未来，servicecomb-kie 配置中心将在数据加密、对接 k8s 生态等方面通过更多支持，使用户更灵活选择方案。

• servicecomb-fence，微服务认证鉴权框架，帮助用户快速构建微服务的认证鉴权能力。

典型的互联网应用不仅需要访问本应用的资源，还需要访问第三方的资源，同时还提供接口给第三方使用。应用的接入形式是多样化的，有手机，WEB 客户端，API 访问等。认证的方式包括用户名密码、手机验证码、人脸识别等。面对复杂场景，在微服务架构中，如何构建分布式、安全和高效的认证鉴权机制是用户关心的问题。

servicecomb-fence 提供开箱即用的标准化认证流程框架代码，它结合 Oauth2.0 和 OpenID Connect 协议，实现 Oauth 4 种认证模型、Token 和 Session 组合的认证机制，支持微服务内部认证鉴权、对接第三方认证鉴权服务、为第三方提供认证鉴权服务等应用场景，帮助用户快速搭建高性能、安全的微服务认证鉴权能力。

华为云微服务架构师谈“黑科技”微服务拆分创新实践

华为云在 17 年将商用了 3 年的微服务框架 ServiceComb 完全开源并捐赠给 Apache 之后，继续基于 ServiceComb 在微服务应用平台 ServiceStage 上提供商业云服务，并持续投入与创新，作为社区开发主力积极回馈社区。本次活动，华为云微服务架构师王启军为大家带来了解决用户最关心的微服务拆分痛点问题的创新实践。

• 微服务自动拆分工具

• 

对于用户和开发者来说，微服务改造第一大难题就是服务如何拆分。服务拆分需要考虑的方面很多，团队大小、交付周期、业务方向、故障范围、数据规模、吞吐量、一致性等都是影响拆分结果的因素，并且可能涉及业务、平台、DBA、测试、运维等多职能部门的协同。

微服务拆分并不是一个容易的工作，如果服务拆分不合理，会给用户带来服务数量爆炸而运维复杂、服务数量太少而不够灵活、接口频繁变更、系统架构复杂度提升等问题；如果是由经验丰富的架构师们来拆分服务，问题可能会减少很多，但是时间、人力成本也会剧增，而且并非所有的团队都拥有有经验的架构师。

综上所言，服务拆分成为遗留应用向微服务转型首要解决的难题。那么，是否有可能通过自动化的工具来替代人去实现一些业务分析、拆分工作，从而解放开发者手脚，降低微服务入门门槛呢？从最关键的拆分数据库/表的典型场景入手，华为云微服务团队开启了微服务自动拆分工具化的探索，通过从遗留应用中解析 DAO 对象、提取 SQL 语句和业务访问日志等客观指标的方法，提供自动拆表、微服务建模和生成代码的功能，工具具备的特征：

• 当业务很复杂的时候，工具可以帮助用户自动梳理出业务逻辑和关联度。

• 从数据库中的表关联关系和代码中 model 的关联关系我们能够分析出表之间的关联度。

• 从表中的数据量和访问日志我们能够分析出业务的核心程度。

目前，微服务自动拆分工具已迈出第一步，具备作为辅助性工具支持微服务拆分的输入参考，后续将在支持搜集和分析更多相关指标（比如研发人员的数量、产品未来的发展方向、交付周期等等这些比较主观的因素）、提高自动化度、提高拆分精确度等方面做更深一步的探索和验证。未来，希望将微服务拆分工具开源出来，联合社区用户和开发者力量共同发展。

“到底工具能不能代替人去拆分呢？是能的，之所以说不能，是因为指标不够全面，不够准确。当我们掌握了足够的指标之后，工具比人做的决策更准确。但是，现在我们的指标还没有那么全面，那么准确，所以，现在工具更多的是辅助性的，但是，未来一定可以做到”王启军表示。

主题演讲精彩互动问答收录

在主题演讲结束后，现场与会的开源爱好者和微服务开发者与演讲嘉宾进行了积极的互动交流，小编摘录了社区用户和开发者最关心的典型问题：

Q1: 在中国，人们习惯使用微信交流，而 Apache 基金会项目是需要使用邮件列表交流的。我想请问在发展新用户的过程中，需要怎样处理这些习惯上的障碍？

Justin Mclean: 其实很容易的，我觉得项目决策是很重要的事情，它应该被记录在邮件列表中。在邮件列表中探讨和记录问题，可以做到有迹可循，有助于新加入的用户了解项目。只要做到这一点，其他都不是问题。

Q2: 作为一个学生，如何参与一个开源小项目，有没有什么建议？

Justin Mclean: 首先要找到一个你感兴趣的项目，项目里一般会有相关的问题列表，你可以从一些容易达成的目标，特别是一些文本修复任务入手。

Q3: 我想问的是作为一个 PMC 成员，我想要参加更多的社区，我需要以怎样的方式开始？

Craig Russell：其实在 Apache 里，很多人是对多个项目进行贡献的。做贡献的方式有很多形式，如果你对一个项目有兴趣，你可以去读读他们的文档，然后脑子里就会产生问题，那么问问题也就是你贡献社区的的一种形式。因为你问这个问题，意味着肯定有一些内容不太清楚、不太清晰。

你问出这个问题，就会促进社区去改善。或者你找到一个 BUG，哪怕他只是一个拼写的错误，你只需要在写邮件或者在相关的邮件后面跟帖，你就做了贡献。如果后面你看见其他人也在提这个问题，把你所知道的告诉他，也是贡献的方法。贡献不仅仅是写代码。

Q4：怎么样去评估微服务自动化拆分工具的拆分质量？

A：拆分质量的衡量指标很多，更多的时候是主观的感受，难以量化。比如：对于注重交付速度的团队，会尽可能的将服务拆分得小；对于注重组织架构的团队，会以降低业务复杂度，使团队配合、交流以及技术演进更加方便，这时候可能就要拆的更小；而对于注重性能的团队，如果服务拆太小，可能会带去资源占用变高、调用链路增长、响应时间增加的情况。

Q5：刚提到 ServiceComb 提供了一个叫 Mesher 的项目，请问它是和 Istio 一样的解决方案么？之前大家对 Istio 的性能有诟病，不知道 ServiceComb-Mesher 有做这方面的优化么？想在是否可以用于商用阶段？

A：ServiceComb-Mesher 与 Istio 不是一个对等的东西，你可以理解为 Mesher 是服务网格 Sidecar 的一种实现，只是在里面做了一些治理能力的扩充。对于 Mesher 最主要是它是一个微服务多语言支持的解决方案，它不绑定运行环境，K8S、裸机都可以使用。ServiceComb-Mesher 是先商用后开源，具备商用要求。

Q6：刚提到的微服务改造工具可以帮助用户将普通应用装换为基于 ServiceComb 的微服务，并形成一些 API 文档。我想问的是转换后的工程是直接可运行的么？转换后需要人工介入修改代码吗？工作量有多少？语言的亲和性怎么样？能不能稍微讲解一下？

A：可以理解 ServiceComb-Toolkit 生成的是一个微服务脚手架工程，目前还不支持将业务代码一并迁移，但生成的微服务工程是可以直接运行的。它已经做好的项目的基本配置，pom、java 包依赖、框架代码等，用户需要做的就是基于通讯接口迁移具体的业务实现。对于业务代码的迁移，其实是有一些想法的，比如说可以引入 AST 抽象语法树对业务代码进行分析。当然也欢迎大家一起来提意见，一起参与进来，一起来完成这些想法。

在此感谢姜宁、王启军提供部分内容素材。