微服务，也就是微服务化的转型实践的分享内容

2021年4月25-26日，全球建筑师峰会（上海站）举行。大会共设18个议题，112位国内外资深技术专家分享76个议题，吸引了900余名技术经理、软件开发工程师和架构师参会。

在数据治理与流量管理创新实践专场上，博云微服务产品架构师张军发表了《如何稳步实施敏感微服务转型》的主题演讲。并分享了多家证券银行微服务改造的实践路线。

据了解，全球架构师峰会是一场专注于高端技术管理者和架构师的技术会议。54% 的参与者有 8 年以上的工作经验。会议聚焦行业强项技术成果，展示了行业先进技术的典型实践，以及技术在推动企业转型发展中的作用。

以下是博云对敏捷微服务转型实践的分享：

01时代的现状，微服务

大家好！今天要和大家聊的话题是微服务，也就是微服务的改造。首先，请想一想企业为什么要做微服务。

如果你的企业系统是自己开发的，不管是什么业务系统，办公系统，核心系统，都是自己开发的，那么做不做微服务可能问题不大。但是，如果你需要购买第三方系统，或者你有一些系统想使用市面上成熟的解决方案，你会发现你需要购买的东西基本上都是微服务做的，而且基本上都是用的微服务的架构做到了。

引入微服务后，企业内部的单体和传统系统都改成微服务，这当然是不可能的。但是，如果现在不启动微服务，将来也会遇到单体和传统系统被迫成为微服务的问题。这就是当前时代的现状。微服务是这个时代的现状。十年前大家都听过一个词叫“信息化”，五年前有一个词叫“服务化”，现在又有一个词叫“数字化”。相信大家应该都听说过数字化，但是很少有人能清楚的解释什么是数字化以及如何去做。

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

这算不算盲目跟风？事实上，许多客户都非常冷静和聪明。客户主要看价值，利用容器、微服务等新技术来跟随数字化思想的发展。这是正确的吗？客户会有一个考量，即考虑数字化转型的“核心价值”。企业数字化转型的核心价值或核心目标无非是降低成本、增加利润、提高效率。如果满足这三点，就证明技术或想法是有价值的。如果不符合这三点，就要考虑是否适合做。

但是，数字化转型必然会引入一些新技术。这些新技术是否会给企业带来更多的开销和更多的运维和管理成本投入？通常它会。

我们在金融和能源行业等传统行业的许多客户可能会通过容器和微服务体验数字化转型。容器主要包括：资源、网络、存储。微服务在整个过程中涉及更多工作，包括治理和观察。

上图是我们农业业务客户之一的微服务改造状态。这里的虚线代表网络隔离和网络区域。我们可以看到，银行的存贷款等核心系统通常都放在稳态区。稳态区的系统特点是运行多年，二是技术架构过时（通常是SOA架构，单体系统）。此外，在相对外围的网络区域，即敏感区域，通常会放置一些非核心系统架构师，例如办公系统。敏感状态区的特点是一般采用新技术完成，即使是单一系统，也采用更通用的技术框架或通信协议。

稳态与敏感态并存，是目前银行客户微服务改造的现状。

02 众多的建筑都是负面的教材

在微服务建设的过程中，我们也遇到了很多错误的想法。在这里，我们与您分享以下内容。希望大家在微服务建设中能避免这些负面思想，并能从这些负面思想中总结出来。微服务改造和微服务改造的正确思路。

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

首先是微服务拆解。提到微服务，首先想到的就是拆分。微服务应该如何拆？拆分后，微服务完成了吗？不是这样。微服务拆分很困难，但不是重点。

我们曾经遇到一个能源客户的需求：客户有130多个业务系统，计划在一年半内将130多个业务系统拆解成微服务。那么他们是怎么做到的呢？第一步是找一个有微服务拆分经验和技术能力的厂商（也就是我们博云），让我们先教他们如何用拆分来拆分微服务。第二步，在积累经验的基础上，与我司再拆30台，作为培训，练习拆解。最后，客户技术熟练，感觉这样拆一个系统，这样拆100个系统，就可以了。然而，事实上，这种构造会引起很多问题。当30个被拆除时，

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

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

负面教材2：试点验证，过早下结论微服务改造效果

第二个消极的建设思路是，企业在改造微服务时，会先安排一个非核心、非关键的系统进行测试。试点的验证效果通常会有以下几种情况： 性能消耗增加。观察需要检测探针，增加探针会增加性能消耗。资源消耗增加。微服务的运行是基于组件的，每个组件都是高可用的。当部署这些组件时，资源将呈指数级消耗。管理比较复杂。制度由少变多后的管理是很不一样的。运维成本增加。部署、变更、故障定位更加困难，需要新的运维方式。

这种试探性的构建会导致企业客户过早地对微服务改造的效果下结论。比如很多企业在构建微服务的时候，都会先做个试点去尝试。在一两年内停止做微服务。但是后来我发现，不做微服务是不够的，因为公司里面有很多微服务系统，不可能只跑一个系统。这时候公司会想，是不是因为之前找的微服务厂商不好，然后花10倍的价钱找大厂商开发一套微服务，最后发现还是不行好的。这些情况是存在的。那么搭建微服务平台究竟有什么重要性呢？

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

1、微服务平台只是一个治理平台。很多企业客户认为微服务平台基本上就是一堆开源组件功能，没有实际意义。比如我们之前也遇到过这种情况。在为客户完成微服务平台搭建后，客户表示微服务平台中的功能基本都是由开源组件组成，比如服务注册和发现、统一配置管理等。、服务、网关等之间的相互访问，基本上开源框架都可以解决这些问题。那么客户自然会问，既然有这些开源组件，为什么还要搭建微服务平台呢？

2、只需使用采购业务系统自带的治理平台即可。很多客户在购买一些第三方业务系统时，发现该业务系统是微服务架构，自带治理平台，具有限流、熔断、观察等功能，可以直接使用。当客户看到它是一个免费的内置管理平台时，他们可以直接使用它，但是使用它之后，他们发现它并没有什么特别之处。

所以，我在这里想告诉你的是，开源工具只是功能实现，而不是治理。治理的核心不是技术角度的功能实现，而是业务角度的管理和观察。例如，从业务角度来看，130个业务系统在公司内部基本划分为区域和部门。如果我们想知道哪个业务系统运行良好，我们首先需要找到它属于哪个部门，然后才能找到它。而不是在 130 个业务系统的列表中搜索。

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

03 微服务前途渺茫，至少哪一步没有错

通过上面的内容，你可能会疑惑微服务建设怎么做？采取哪一步至少不会犯错？下面我给大家讲一下微服务搭建的第一步是怎么做的。

1、不求大局者，不足以谋域。这句话的意思是，微服务的建设必须由整个企业、整个公司来进行，而不仅仅是一个小部门、一个小业务系统进行简单的试点。不建议大家这样做，因为容易陷入 找个领域是不够的，也就是说虽然试点做了微服务，但是发现都是白费。

2、那些不寻求永生的人，一时是不够的。这句话的意思是说，微服务的建设，一定要清楚未来的发展路径是什么，现在应该把重点放在哪里。在开始构建微服务之前，让我们回顾一下微服务的一些特性和优势。

微服务的概念是企业微服务建设的指南和目标。当然，在微服务建设的初期，我们会发现离理想的微服务实现还有一段距离。微服务有很多特点，但最主要的就是独立性。包括独立部署、独立运营、独立开发、独立管理、独立团队等。独立的好处是自由，容易改变。

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

一是统一应用服务管理。在面向服务的体系下，应用服务统一管理，方便企业搭建中间平台或开放能力。

二是统一权限控制管理。服务之后，需要做好访问控制和流量控制，这是微服务必须的。该服务不能随意访问，也不能受到大流量的影响。

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

四是统一设计服务体系。从全局出发，提炼业务系统的特点。这是一个统一的设计，然后有针对性的拆分。在拆分中，一定要把握刚才提到的特点，首先要从统一的业务系统、统一的拆分、统一的性能评估、统一的架构评估入手。

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

在了解了微服务的特点和价值之后，我将与大家分享如何稳步实现微服务以及从哪里入手。

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

1、项目创建和管理：从项目/业务平台的角度创建项目管理。

2.资源准备：项目启动后，开始准备相应的开发、测试、生产环境所需的资源，或者直接连接资源平台。

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

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

5、运营管理：监控和管理服务的运营状态，反馈运营过程中的服务优化和变化。

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

在这六个阶段中，可以分为三种运行状态，而微服务的建设要从这三种运行状态入手。

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

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

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

微服务建设建议从运行态开始，第一步是运行态，第二步是开发态，第三步是运维态。为什么要先从运行状态开始？从运行状态入手，可以深刻明确在开发状态下需要做哪些修改和规范，比如将SDK注入治理规范。（我们下周微服务系列文章会详细说明为什么要从运行状态开始构建微服务）

从微服务建设的运行状态出发，我们会发现微服务建设的实施会有很多困难，主要有以下三点：

一、SOA架构如何统一集成处理？SOA架构是大多数证券银行公司的现状，只能逐渐被替代，集成方式根据通信协议确定。

二、现有业务系统如何兼容？很多现有的、非微服务的单体应用都需要有统一的管理、治理、监控、告警功能。

第三，微服务的开发和使用规范。无论是观察、日志、链接，还是想在运行状态下添加高性能压测，都需要先编写规范，完成规范上线前，连接压测平台，然后启动. 经过压力测试，这个标准的微服务构建是最大最核心的东西，而不是微服务的拆分。

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

首先，放眼全球。微服务的建设需要全面统一的考虑。

二是与当下相适应。并不是所有的企业系统都换成微服务，所以要兼容现在的，现有的老系统也要完美兼容。

第三，直接指向未来。微服务的建设需要着眼长远，确定未来的发展方向，搭建统一规范的平台。如果现在不能实现标准化，以后很容易出现各种问题。今天的分享就到这里架构师，谢谢。

类型：广告