博云出席2021全球架构师峰会 分享敏态微服务化转型如何稳步落地

2021年4 月 25-26 日，ArchSummit 全球架构师峰会（上海站）在上海宝华万豪酒店举办。大会共设 18 个专题，共有来自国内外的 112 位高级技术专家围绕 76 个话题进行了分享，吸引超过 900 位技术管理者、软件开发工程师与架构师与会交流。

BoCloud博云微服务产品架构师张俊在数据治理与流量管理创新实践专场上，带来《敏态微服务化转型如何稳步落地》的主题演讲，内容以博云多年微服务化研究落地经验，总结并分享了诸多证券、银行的微服务化转型实践路线。

据了解，ArchSummit全球架构师峰会是重点面向高端技术管理者、架构师的技术会议，54%参会者拥有8年以上工作经验。会议聚焦业界强大的技术成果，展示先进技术在行业中的典型实践，以及技术在企业转型、发展中的推动作用。

以下是博云关于敏态微服务落地转型实践的分享内容：

01时代的现状，微服务化

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

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

微服务的东西拿来之后，企业内部单体的、传统的系统就都改为微服务的，这当然是不可能的。但是，如果现在不开始做微服务，未来也会遇到单体、传统的系统被迫改为微服务化的问题，这是目前时代的现状。微服务化就是这个时代的现状。十年前大家都听过一个词叫“信息化”，五年前有一个词叫做“服务化”，现在有一个词叫“数字化”。我相信大家应该都听到过数字化，但是能够把数字化是什么，怎么做讲清楚的人是少之又少。

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

那这样做算不算盲目跟风？其实很多客户都很冷静、很聪明。客户主要看价值，用容器和微服务等新技术，跟着数字化的思路发展，这样做是不是对的，客户会有一个考量，也就是考量数字化转型的“核心价值”。企业数字化转型的核心价值或者核心目标无外乎是降低成本、增加收益、提高效率。如果符合这三个点，证明这个技术或者思路是有价值的，如果不符合这三点，就要考量一下到底适不适合去做。

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

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

上图是我们某农商客户的微服务转型现状，这里用虚线隔开的代表网络隔离和网络区域。我们可以看到，通常银行的存款、贷款等核心系统会放在稳态区域，稳态区域的系统特点一是运行多年，二是技术架构陈旧（一般是SOA架构，还有单体系统）。另外，在比较靠外的网络区域，也就是敏态区域，通常会放一些非核心类的系统，如办公系统等。敏态区域的特点是一般采用新技术来做，即使是单体系统，也是用较通用的技术架构，或者通信协议。

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

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

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

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

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

我们曾在一个能源客户中遇到过一种需求：客户有130多个业务系统，计划在一年半时间内，把130多个业务系统全部拆成微服务。那他们是怎么做的呢？第一步，他们先找到一个有微服务拆分经验并有技术能力的厂商（也就是我们博云），让我们先以一个拆分来教他们微服务怎么拆。第二步，在有了经验的基础上，在我们的陪同下再拆30个，作为练兵来把拆分练熟、练会。最后，客户技术练熟了，觉得1个系统是这么拆，100个系统也是这样拆，就可以了。然而，实际上这样建设会产生很多问题，在拆到30个的时候，各种问题就会纷涌而至，根本不可能拆到130个。所以说微服务化建设≠微服务拆分。

微服务拆分之后会面临以下问题：微服务拆分之后，成千上万个服务如何管理？资源消耗增加，甚至是翻倍增长。运维难度增加，效率低下。人力和时间成本投入增多，收益怎么找？

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

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

第二种反面建设思路，通常企业做微服务转型时，会先安排一个非核心非关键系统进行试验，试点的验证效果通常会有以下几种情况：性能消耗增加。观测需要检测探针，只要加上探针都会增加性能消耗。资源消耗增加。微服务的运行基于组件，每个组件都是高可用，这些组件部署下来会导致资源成倍的消耗。管理更为复杂化。系统由少变多之后的管理是有很大差别的。运维成本增加。无论是部署，还是变更、故障定位都更困难，需要全新的运维方式。

这种试探性的建设，会导致企业客户过早地对微服务转型效果下结论，比如：很多企业在做微服务建设的时候，首先拿一个试点去试，试完之后发现没有什么用，过了一两年就不再做微服务了。但是越到后来发现不做微服务还是不行，因为公司的微服务系统有很多，不可能只让单个系统去运行。这个时候企业就会想，是不是之前找的微服务厂商不行，接着再花10倍的价钱找一个大厂再搞一套微服务，最后发现还是不行，这些情况都是存在的。那么建设微服务平台的重要性到底是什么？

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

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

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

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

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

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

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

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

2、不谋万世者，不足以谋一时。这句话的意思是说，微服务化建设一定要想清楚未来发展路线是什么样的，以及现在应该聚焦在哪里。在开始进行微服务建设的时候，我们先回顾一下微服务的一些特征和优势。

微服务的理念是企业微服务化建设的指引和目标，当然在微服务化建设前期，我们会发现距离完美实现微服务所阐述的理念还是会有些距离的。微服务的特征有很多，但最主要的是独立。包括独立部署、独立运行、独立开发、独立管理、独立团队等，独立的好处是自由，这样便于改动。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

第二，存量业务系统如何兼容？诸多存量的，非微服务化的单体应用，统一纳管、治理、监控、告警功能都需要具备。

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

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

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

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

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