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 抽象语法树对业务代码进行分析。固然也欢迎你们一块儿来提意见，一块儿参与进来，一块儿来完成这些想法。

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

本文转载至infoq

原文连接：https://www.infoq.cn/article/dbMDURNo0BCyh8Ivxxcb