导读

本文为 4 月 25 日全球架构师峰会——数据治理与流量管理创新实践专场上，博云微服务产品架构师张俊《敏态微服务化转型如何稳步落地》的分享实录，内容以博云多年微服务化研究落地经验，总结并分享了诸多证券、银行的微服务化转型实践路线。

01 时代的现状，微服务化

大家好！今天我想跟大家聊的话题是微服务，也就是微服务化的转型。首先请大家想想企业为什么要做微服务化。

如果你的企业系统都是自己研发的，不管是什么业务系统、办公系统、核心系统也好，都是自己研发，那做不做微服务化，可能没有太大的问题。但是，如果你需要采购第三方的系统，或者你有一些系统想要用到市面上成熟的方案，这个时候你会发现你需要采购的东西基本都是用微服务化做的，基本都是用微服务的架构做的。

微服务的东西拿来之后，企业内部单体的、传统的系统就都改为微服务的，这当然是不可能的。但是，如果现在不开始做微服务，未来也会遇到单体、传统的系统被迫改为微服务化的问题，这是目前时代的现状。微服务化就是这个时代的现状。

十年前大家都听过一个词叫“信息化”，五年前有一个词叫做“服务化”，现在有一个词叫“数字化”。我相信大家应该都听到过数字化，但是能够把数字化是什么，怎么做讲清楚的人是少之又少。

我们也遇到过很多这样的客户，像证券、银行、能源、交通等各行业的客户，虽然他们说不清楚数字化未来是什么样，但是他们知道现在用一些新型的技术是没有问题的。比如，十年前跟着云计算走，五年前开始搞容器和微服务，现在都在讨论云原生，这就是在跟着数字化的思路。

那这样做算不算盲目跟风？其实很多客户都很冷静、很聪明。客户主要看价值，用容器和微服务等新技术，跟着数字化的思路发展，这样做是不是对的，客户会有一个考量，也就是考量数字化转型的“核心价值”。

企业数字化转型的核心价值或者核心目标无外乎是降低成本、增加收益、提高效率。如果符合这三个点，证明这个技术或者思路是有价值的，如果不符合这三点，就要考量一下到底适不适合去做。

然而，做数字化转型势必要引入一些新技术，这些新技术会不会给企业带来更大开销，更多的运维和管理成本上的投入呢？通常来讲会的。

我们很多传统行业的客户，像金融、能源行业，这些客户的数字化转型可能会通过上容器和用微服务。容器主要包括：资源、网络、存储。而微服务涉及的贯穿工作会更多，包括治理、DevOps 和观测。

上图是我们某农商客户的微服务转型现状，这里用虚线隔开的代表网络隔离和网络区域。我们可以看到，通常银行的存款、贷款等核心系统会放在稳态区域，稳态区域的系统特点一是运行多年，二是技术架构陈旧（一般是 SOA 架构，还有单体系统）。

另外，在比较靠外的网络区域，也就是敏态区域，通常会放一些非核心类的系统，如办公系统等。敏态区域的特点是一般采用新技术来做，即使是单体系统，也是用较通用的技术架构，或者通信协议。

稳态与敏态共存是目前该银行客户的微服务转型现状。

02 众多的建设，皆是反面教材

在微服务化建设过程中，我们也曾遇到过很多错误的思路，在这里和大家分享以下，希望大家在微服务建设中大家可以避开这些反面思路，并从这些反面思路中能总结出微服务化改造和微服务化转型的正确思路。

反面教材 1：微服务化建设=微服务拆分

首先是微服务拆。一提到微服务，大家首先想到的就是拆分。那微服务到底应该怎么拆？拆分之后，微服务就完成了吗？其实并不是这样的。微服务拆分是难点，但不是重点。

我们曾在一个能源客户中遇到过一种需求：客户有 130 多个业务系统，计划在一年半时间内，把 130 多个业务系统全部拆成微服务。那他们是怎么做的呢？

第一步，他们先找到一个有微服务拆分经验并有技术能力的厂商（也就是我们博云），让我们先以一个拆分来教他们微服务怎么拆。第二步，在有了经验的基础上，在我们的陪同下再拆 30 个，作为练兵来把拆分练熟、练会。最后，客户技术练熟了，觉得 1 个系统是这么拆，100 个系统也是这样拆，就可以了。

然而，实际上这样建设会产生很多问题，在拆到 30 个的时候，各种问题就会纷涌而至，根本不可能拆到 130 个。所以说微服务化建设≠微服务拆分。

微服务拆分之后会面临以下问题：

• 微服务拆分之后，成千上万个服务如何管理？

• 资源消耗增加，甚至是翻倍增长

• 运维难度增加，效率低下

• 人力和时间成本投入增多，收益怎么找？

这些都是在项目中遇到的实际问题。

反面教材 2：试点验证，过早对微服务转型效果下结论

第二种反面建设思路，通常企业做微服务转型时，会先安排一个非核心非关键系统进行试验，试点的验证效果通常会有以下几种情况：

1. 性能消耗增加。观测需要检测探针，只要加上探针都会增加性能消耗。

2. 资源消耗增加。微服务的运行基于组件，每个组件都是高可用，这些组件部署下来会导致资源成倍的消耗。

3. 管理更为复杂化。系统由少变多之后的管理是有很大差别的。

4. 运维成本增加。无论是部署，还是变更、故障定位都更困难，需要全新的运维方式。

这种试探性的建设，会导致企业客户过早地对微服务转型效果下结论，比如：

很多企业在做微服务建设的时候，首先拿一个试点去试，试完之后发现没有什么用，过了一两年就不再做微服务了。但是越到后来发现不做微服务还是不行，因为公司的微服务系统有很多，不可能只让单个系统去运行。这个时候企业就会想，是不是之前找的微服务厂商不行，接着再花 10 倍的价钱找一个大厂再搞一套微服务，最后发现还是不行，这些情况都是存在的。

那么建设微服务平台的重要性到底是什么？

通常企业客户对于建设微服务平台会有两个误区。

1、微服务平台只是一个治理平台。很多企业客户认为微服务平台基本上是开源组件功能的堆叠，没有实际意义。举个例子，我们之前遇到过这种情况，在给客户做完微服务平台建设之后，客户说这个微服务平台里面的功能基本都是开源组件构成的，像服务注册和发现、统一配置管理、服务间互相访问、网关等，基本上开源框架就可以解决这些问题。那客户自然会问，既然有这些开源的组件，何必再需要建设一个微服务平台呢？

2、使用采购业务系统自带的治理平台就行。很多客户在采购某些第三方业务系统时，发现这个业务系统是微服务架构的，并且自带一个治理平台，限流、熔断、观测等功能都有，可以直接使用。客户一看既然是免费的自带的治理平台，那就直接使用吧，结果用之后发现并没有什么特别的。

所以，这里我要告诉大家的是，开源的工具只是功能的实现，而不是治理。

治理的核心不是技术角度的功能实现，而是业务角度的管理和观测。举例而言，业务角度 130 个业务系统在公司内部基本都要划分区域和部门，如果我们想知道哪个业务系统跑得怎么样，首先需要找它是哪个部门的，然后才能找到。而不是在 130 个业务系统的列表去里面搜。

治理的核心在于管理，管理是最重要的。从一个企业大体的方向出发，真正的管理才是最重要的。

03 微服务化前途渺茫，走哪步至少不会错

通过上面的内容，大家可能会想那做微服务化建设到底应该怎么做？走哪一步至少不会犯错？现在我来告诉大家微服务化建设第一步该怎么做。

1、不谋全局者，不足以谋一域。这句话的意思是说，微服务化建设一定要全企业全公司一起统一搞，而不要只是一个小部门、一个小业务系统去简单试点，不建议大家这样做，是因为仅仅试点很容易陷入到不足以谋一域的场景，也就是说虽然试点做了微服务，但之后发现全是白搞。

2、不谋万世者，不足以谋一时。这句话的意思是说，微服务化建设一定要想清楚未来发展路线是什么样的，以及现在应该聚焦在哪里。

在开始进行微服务建设的时候，我们先回顾一下微服务的一些特征和优势。

微服务的理念是企业微服务化建设的指引和目标，当然在微服务化建设前期，我们会发现距离完美实现微服务所阐述的理念还是会有些距离的。

微服务的特征有很多，但最主要的是独立。包括独立部署、独立运行、独立开发、独立管理、独立团队等，独立的好处是自由，这样便于改动。

微服务的价值主要是服务化、复用性、平台化和标准化。这里面最重要的价值是标准化，主要包括以下四点：

第一，统一应用服务管理。服务化体系下，应用服务统一管理，便于企业建设中台或做能力开放。

第二，统一权限控制管理。服务化以后，要做好访问的控制和流量的控制，这个是做微服务必须要做的一点。服务不能随意访问，也不能让大流量冲击。

第三，统一技术架构规范。在前两项之前，要先统一技术框架、统一通信协议、统一编码规范、统一的运维和采集等，便于服务的统一管理，也便于服务内部的统一调用。统一架构规范包括组件规范和研发规范：

第四，统一设计服务系统。从全局入手，提取业务系统的特点，这是统一的设计，之后再有针对性的进行拆分。拆分要把握刚刚说的几个特点，要统一入手去做业务系统，统一的拆分、统一的性能评估和统一的架构评估。

04 如何稳步落地，顺序很重要

了解了微服务的特征和价值后，接下来跟大家分享一下微服务如何稳步落地，应该从哪些方面入手。

上面这张图基本把一个企业内部微服务化从研发到运行的所有状态都展示出来了，也就是这些内容在微服务化中都需要设计。

1. 项目创建和管理：以项目/业务平台视角创建项目管理。

2. 资源准备：项目启动之后，开始准备对应的开发、测试、生产环境所需的资源，也可以直接与资源平台对接。

3. 开发管理：依托前后端开发框架进行快速地代码迭代开发

4. 运维管理：统一发布，应用发布管理、API 上线管理等。（开发和运维管理多数涉及到 DevOps，这是微服务启动运行的主要关键。）

5. 运行管理：对服务等运行态进行监控和治理，服务优化、变更都在运行中反馈

6. 能力外放：不管是企业内部要建服务中台，还是企业对外开放一些能力平台，都可以在这里去提取

在这六个阶段当中，可以分为三个运行态，微服务化建设就是要先从这三个运行态开始。

1. 开发态：包括项目管理和开发管理。

2. 运维态：包括资源准备和运维管理。

3. 运行态：包括运行管理和能力开放。

微服务化建设建议大家从运行态入手，第一步运行态，第二步开发态，第三步运维态。为什么先从运行态入手？从运行态入手，可以深刻地明确在开发态需要做哪些改造和规范，例如注入治理规范的 SDK。(关于为什么从运行态入手微服务化建设，我们会在下周的微服务系列文章中详细阐述）

从运行态入手微服务化建设受，我们会发现在微服务化建设实施中会遇到很多难题，主要有以下三点：

第一，SOA 架构如何统一集成处理？

SOA 架构是多数证券、银行企业的现状，只能逐步替代，并视通信协议来定集成方式。

第二，存量业务系统如何兼容？

诸多存量的，非微服务化的单体应用，统一纳管、治理、监控、告警功能都需要具备。

第三，微服务开发和使用的规范。

无论是观测、日志、链路，或者想要在运行态加入高性能的压测，都需要先把规范写好，在上线之前把规范做好，把压测平台对接起来，然后一启动就可以做压测了，这个规范微服务化建设最大、最核心的东西，而不是微服务拆分。

最后，给大家总结一下微服务化建设应该把握的三点：

第一，全局思考。微服务化建设需要全盘统一考虑

第二，兼容当下。企业系统全都替换成微服务是不显示的，所以必须兼容当下，对已有的老系统要做到完美兼容。

第三，直指未来。微服务化建设需要从长远角度出发，确定未来发展方向，建设一个统一标准化平台，如果现在做不到标准化，后面会很容易出现各种问题。

以上就是我今天的分享，谢谢大家。

Q&A 环节

Q1 如何在微服务架构下保证数据的一致性？

A1：数据一致性是指分布式事务吧，这个东西我没有列入到里面来，因为这个话题是很多客户提到的。一开始做微服务进去的时候，客户会提你们的分布式事务怎么做的？我们也会给一些相应的方案，比如说 Seata，通过 mq 最终一致性的这些都有，做到后来发现现在很少用到分布式事务。之前跟一个客户聊的时候，说在开发态把分布式事务做好，让研发人员不要去花太多的成本和太多的学习在这个上面，把这一块分拔到底层（音）直接使用就好，这个想法是好，但其实没有用的。如果涉及到分布式事务的，尽量避免这一块。如果觉得不满意，我们有很多架构师可以给你提供一系列的分布式方案。

Q2 我想问一下微服务在企业做的时候既统一又要分布，你们做统一和分布的时候，到底怎样去界定微服务？

A2：统一是要统一标准、统一规范，这个是要统一的。另外，最好要有统一的设计，如果没有也没有关系，因为微服务是一个迭代的过程，最主要是统一规范。在每一个微服务建设的时候，首先要按照统一规范来，这样保证以后更容易变更。

Q3 如果选择博云的话，博云能为我们企业落地微服务提供什么样的帮助？

A3：我刚才提到的都可以，主要在管理层面介绍的比较多，做微服务我们也遇到过一些客户，有的客户说你帮我做拆分，这个没有太大的价值。帮你做拆分，说白了是理论性的占多，如果有一两个业务系统想要做拆分，想要做微服务的初始管理也是可以的，但是它的价值一期做完之后，基本上就没活做了。

Q4 正如您刚才所说的一般企业做微服务的话，会从一些非核心的系统开始来做。我想问一下你们给客户提供解决方案的时候，一般会提供什么样的建议？

A4：2020 年之前我们做了一些案例，基本都有我刚才提到的问题。2020 年之后，我们也找到一些规律了，我们帮你们做微服务，一定要统一的框架、统一的技术架构，为什么？如果两个微服务注册中心都不一样的话，你的资源和刚才所说一堆弊病都会出现。我们帮助客户做微服务一定要先统一，统一使用规范、统一协议规范，这是我们要做的主要方针。

Q5 我是来自于华为的，想请教一个问题，刚才您提到敏态和稳态的微服务，我对敏态蛮感兴趣的。我们做通信行业，敏态跟稳态适不适合用在通信领域，它在金融领域是一个 Case，可不可以在其他领域有应用？

A5：其实稳态和敏态是很早就提出的一个概念，说到底是有一部分没有办法去做微服务化的改造，或者是近期内没有办法做微服务的改造，这一类统称为稳态。另一类有条件，我想做新型的技术架构框架改造，这一类通常叫做敏态。其实所有的行业和企业，只要大家面临到应用服务的系统比较多和管理麻烦，都可以做微服务化的管理和改造。我们也会针对于每一个企业的现状，去做相应的调整，哪些业务系统帮你先做拆分、改造？哪些系统根据企业内部，哪些系统可以先放到稳态区慢慢改造，包括敏态区那一块，也有一些可以先做微服务化的改造，也有可以慢慢往后放一放，都可以。包括稳态区也是，正好有一个好的时期，这个好的时期让我赶紧去做微服务化的改造，那就赶紧入手都可以。

Q6 您觉得有没有一些业务场景适合微服务做分布式部署的方案？或者是一些适合的案例？

A6：你说我把业务系统拆分成微服务了，但是我不做高可用，不做分布式。我们在某一个证券里面也做过类似的，当时它不做分布式，可以不用去使用注册中心，这是一个好的地方。我不用注册中心，有注册中心反而会增加很多麻烦的地方，不做分布式没有扩缩容的需求，我就完全可以不用注册中心做微服务，这也是可以的。但是在变动大的业务流量的业务系统里面，肯定不可能的。但是在刚刚那个客户业务系统里面还是可以的，它的底层是用 K8S，通信协议用 GRPC，它就能这样做。通过 APM 去做一些监控，拿到一些监控数据，这都是可以的。

点击BoCloud博云了解更多微服务解决方案。