【深入浅出，Paas之路】华为云MVP田晓亮：企业向微服务架构转型的几点思考

IDC的报告曾指出，到2021年，在超过一半的全球2000强企业中，平均1/3的数字化服务交互都将来自API开放生态系统，增长势头远超其自身的API交互能力。开放的API生态系统是企业数字化平台开放重构的关键。

据悉，来自 Twitter、Netflix 和 Google 等公司的广受欢迎的公共 API 平均每天调用 10 亿到50亿次，API调用量逐渐成为一个开放平台成功的关键指标，哪些技术可以驱动API快速增长？

拥有12年研发经验的田晓亮给出了他的答案。田晓亮现担任华为云微服务领域首席架构师，他也是国内早期服务网格实践者，曾自研服务网格作为云服务提供给客户业务使用。且听他娓娓道企业数字化转型的关键，以及系统性开展微服务化的一些重要举措。

微服务为何如此重要？

这里引用Smart Bear 2020年的API报告。

如上图所示，微服务技术遥遥领先，成为最关键的领域技术，是企业API经济的技术基石。排在第二的DevOps相关技术则是微服务顺利落地的关键要素和前提。而微服务本身是一种架构模式，这也侧面证明了软件架构设计的价值。

一款软件大部分的生命周期都处在维护期，不断地接受新需求，不断变化演进以满足需求。软件架构设计的主要目标便是支撑软件系统的全生命周期，设计良好的架构可以让系统便于理解、易于修改、方便维护，并且能轻松部署。软件架构的终极目标就是最大化程序员的生产力，同时最小化系统的总运营成本，微服务架构恰好能完美地达成这个目标。

当然，有个题外话，研发人员也不必担心效率提升自己被优化，因为杰文斯悖论在这里也适用：技术进步提高单位人力利用效率，结果是增加而不是减少企业对人力的需求。

是什么阻碍了微服务的应用

接下来再看报告中另一个部分，是什么阻碍一个组织应用微服务？

依次为：

1. 欠缺实践经验和技巧（或者我认为是不易雇佣相关人才）；
2. 现存代码改造难；
3. 工作负担太重，没人（新的需求加入管道，它可以增加营收，此时如果老架构不是业务发展的障碍，就被搁置）；
4. IT成熟度不足、流程问题、基础设施问题；
5. 没预算；
6. 还没确定业务方向；
7. 缺少团队协作；
8. 缺少工具和技术。

因为缺乏上述提到的这些东西，向微服务架构模式前进的企业可谓是千疮百孔。作为云服务提供商，或许可以帮助企业解决这些问题。

田晓亮讲了一个他亲身经历的故事：我曾经拜访过一家企业，他们打算让业务团队在云上买些虚拟机自己搭建基础平台，被我阻拦了下来。因为当他们的业务增长后，会遇到各种各样的平台问题，但又没有相关的人才储备。当他们用开源的软件部署，遇到的生产问题其实需要开源社区的人来解决。而这个企业并没有清晰划分职责的技术组织。从商业视角出发，非主营核心业务通过外来购买付费服务来完成更为合适。另外他们也许进入了一个致命的架构设计误区，在没有确定业务能力的情况下过早的进行了技术选型，而这个工作通常是要延后处理的，平台的维护成本可能会拖垮业务开发团队。

通常情况下，大企业一般会使用云厂商提供的计算、存储等资源，也有自建IaaS服务或者两者并用的，然后在laaS层之上构建PaaS服务，为公司内部的业务服务。所以大型企业会清晰地拆分业务团队与基础设施团队，田晓亮本人就曾是基础设施团队的一员。在这种情况下，基础设施团队也是微服务架构模式的忠实用户。也就是说，他们不但要支撑好平台用户的微服务，自己也应用了该模式。

基于多年的微服务转型经验，田晓亮提炼了几个可以帮助企业完成微服务数字化转型的关键点。

如何系统性的展开微服务化

我们可以围绕软件开发的速度，系统的安全和服务质量来构建微服务相关技术底座。再结合业务的实际发展，逐步转型微服务架构，不必在业务发展初期草草决定技术细节。

匹配业务所需

是否选择微服务架构模式应该从业务实际需求出发，企业先明确定义业务用例和策略，在此基础上进行架构方案的选择。对于一些刚刚起步的公司，单体应用也许就能满足业务需求。

一切以快为准，当单体的开发效率比微服务高时，就果断的选择单体。而随着业务的扩大，企业可以通过绞杀者模式将单体应用向微服务架构模式迁移，进行单体应用绞杀的过程也称为应用现代化的过程。

据维基百科，绞杀模式的使用场景是从单体应用平滑演进到微服务，将遗留应用程序转换为现代技术和技术栈的过程，也可称之为应用程序现代化。

这种模式通常针对1个遗留应用系统，适合前期野蛮成长，业务增速较快的企业。整个改造流程不需要一步到位，一点点补充新的功能进入管道，比如有的功能可以增加营收，此时如果老架构不是企业业务发展的障碍，就可以被搁置并随时重启演进。

具体策略有：

• 新功能用新的微服务实现（阻止单体水平扩展和演进）
• 隔离表示层和后端（降解单体）
• 将现有的功能提取到微服务或者独立为微服务（降解单体）

华为云CSE，解决分布式系统治理之难

从单体成为微服务之后，假如没有成熟的工具配套，一切的成本都是翻倍提升的，这也是为什么说技术没有银弹。运行时的治理就是其中一个难题。

华为云CSE的设计意图就是让企业的治理成本和门槛降低，以保障业务稳定健壮的运行，提供高质量API服务。

CSE微服务引擎提供了基于业务视角的流量治理功能，使用可视化界面规划流量策略，无需关心微服务系统的复杂性。企业需要的只是定义好流量特征，比如登陆操作每分钟只能允许5次。另外使用Spring Cloud编程的应用可以无缝使用云上的能力，无需额外编码。

CSE还提供了RBAC认证鉴权系统，提供基于标签的细粒度资源授权功能，可以规划多个账号，赋予角色和相关权限，保证多个团队协作过程中不会误操作或者访问不该访问的数据。这套认证系统独立于华为云的IAM，类似MySQL的账号系统是完全独立的，这样团队之间就可以安全共享一套微服务引擎。

微服务编程框架or服务网格，业务为王

在进行编程框架和服务网格（Istio）之间的技术决策前，不妨先遵循架构设计阶段一个较好的指导思想——保留可选项，即尽可能推迟技术细节的相关决策。比如先确定业务能力是什么，收集用例，再决定选关系型数据库还是非关系型数据库，亦或是两者皆用。任何一种技术的选择皆如此。

如在Spring Cloud这类编程框架和服务网格之间的选型存在疑虑时，就要充分的分析企业的业务是否匹配这些技术的适用场景，是否能支撑商业成果。因为选择什么技术手段支撑，终究要回归到业务本质来。企业要对多种可彼此替代的技术进行详尽的洞察和对比，结合需要支撑的业务场景做详尽的论证来验证最适合的技术到底是什么。

下边这张表格列举了微服务开发下这两种技术方案的部分特性对比，它并不代表孰优孰劣，只是告诉企业要选择对应的能力来匹配业务、支撑业务。打个比方，Istio能提供绝对的内部网络通信安全，这是它独有的能力，如果企业的业务需要这样级别的防护，那么选择Istio管理会更加方便，而Istio却有很多不关心的维度，而这些维度正式编程框架提供的能力。

管理好API

如果API主要给外部系统调用，最好采用顶层设计的策略。不建议把这些对外暴露的API的设计权放到各个团队手中，因为最外层的、系统平台消费者可见的API必须是定义良好，风格一致的API，并且严格控制兼容性，可以使用CloudTest对这些API编写测试用例，并且在每次部署后，都执行一遍测试用例以确保平台的行为始终一致。

API是业务的门面，可以采用Spring Cloud Gateway开发框架编写对外呈现的API，框架会自动生成Open API文档并注册到CSE微服务引擎实例中，这样可以重点审视API的定义，及时进行改进，高质量的交付所有的API。

从DevOps文化建设入手

当企业全面推动DevOps文化，并熟练让交付团队掌握相关工具后，微服务架构思维必然会在组织里萌芽。团队需要代码库，流水线等一系列服务来打造一条高效的生产线，故此DevOps技术因为其重要性排在了关键技术第二位。如果没有DevOps的成熟建设，就不要展开架构微服务化。

华为云的DevCloud是集华为研发实践、前沿研发理念、先进研发工具为一体的研发云平台,面向开发者提供研发工具服务，让软件开发简单高效

当然，系统性展开微服务化并非只有技术类工作，文化理念、团队合作形式、关键成员不断学习和精进都是微服务化的关键。

总结

简而言之，微服务架构满足了架构设计模式中的单一职责和共同闭包原则，它是业务和商业发展成规模化后的必经之路。微服务既符合架构设计原则，也能最小化系统运营成本，支撑高效的商业活动，在激烈的竞争中起到了“润滑剂”的作用。所以，你的业务是否已经准备好应用微服务了？