微服务转型的三大误区，避坑指南→

导读

本篇文章为博云微服务转型系列第二篇文章。

 

在之前文章中我们讲到企业的数字化转型（详情回顾：农商行数字化转型的烦恼），通常两种技术的运用代表着数字化转型的实践，一种是容器技术，一种是微服务技术。容器技术的建设和使用都是运维，因此更容易快速上手和建设。但是，微服务技术就不同了，微服务架构的起点是研发，治理却在运维，架构反馈和改进又要回到研发（当然这是传统的企业管理模式下的），所以传统企业在微服务化建设时，会遇到很多微服务的相关问题和误区。

 

本文我们将对微服务化转型的常见误区进行了整理，并分享一些如何避开这些误区的建议和想法。

 

通常企业的数字化转型和系统的微服务化改造很容易被放在一起讨论，这样的说法是把微服务放到了一个系统级别，也就成为了一个部门或一个团队的任务。这其实就是一个企业刚开始做微服务转型的最大误区。

 

微服务化转型是企业级的改造工程，而具体的落实才是系统的改造，只关注于系统的微服务化改造，难免会“守一隅而遗万方”。其实，企业微服务化转型的很多误区都是这样产生的。

 

01 微服务拆分的误区

 

博云一直为企业提供微服务拆分的咨询服务，所以经常会接到微服务拆分的项目。有些客户通常只要咨询、只要方法论、只要单个系统拆分的服务，这样的方式其实都走入了微服务建设的误区。例如，我们之前遇到一个大企的微服务化转型项目，涉及近百个业务系统的微服务改造建设。面对这么大的微服务化建设，客户的想法却很简单，计划整体改造分成三步：

 

第一步：找一个对微服务拆分比较专业的公司，帮忙做第一个系统的拆分工作，并学习微服务拆分的精髓。

 

第二步：在咨询公司的帮助下，自行拆分二三十个业务系统，作为练兵。

 

第三步：摆脱咨询公司的帮助，拆分改造剩下的系统。

 

很明显，这是为了拆分而拆分。这样的建设相当于是单体应用系统平等地置换成微服务系统的应用，导致单体应用的优势没有了，而微服务的优势也并没有体现出来。可以预见，如果继续这样建设会出现很多麻烦：

 

1. 业务系统由近百个变成近千个，完全颠覆了原来的管理模式。以前只需要在资源层面、网络层面的监控运维，而对于现在服务层面的观测简直束手无策。

    

2. 如果只是单系统的考虑拆分，那么微服务带来的消耗是会增加的。微服务的拆分将一个运行程序拆成了十几个，还要依赖于必要的组件，如注册中心、配置中心、网关，当然每个都需要考虑高可用，那么在资源消耗上，将增加不止一倍的消耗，这样算来，整个企业的微服务改造，将可能会多改造出一个机房来。

    

3. 刚刚提到监控运维，其实运维层面还有更多的问题。上百个系统，近千个服务，再加上分布式的部署方式，将有几千个运行程序的部署和升级迭代，这绝对不容小觑。

    

4. 每个改造、建设，或者变革，都会被问到一个收益的问题，投入大量的人力、物力、财力，我们想要看到的是回报，而这种方式的拆分将只有投入。

微服务化转型，或者说微服务化建设，绝对不等于微服务的拆分。微服务的拆分仅针对于某一个系统，或者几个系统，跟架构师、研发人员比较密切相关。而微服务化的建设，其实针对的是整个企业的管理、运维，并关系到所有的微服务系统的研发和运维团队。所以企业在做微服务化转型的时候，我们应该把握微服务的优势，发挥其长处，弥补其不足。
不要把微服务建设，做成了微服务批量拆分，这是要注意的第一个误区。

 

 

02  微服务化建设的误区

 

谈到这里似乎应该说：“不要为了微服务而微服务”，但实际上为了微服务而建设微服务也不是问题，因为云原生理念与技术的普及已经如火如荼，所以熟悉相关技术也是势在必行。

 

很多企业看到了微服务的前景，也开始在架构、研发等部门中，建设一些微服务治理平台或者微服务运行观测平台，但是通常这类的试验性质的项目都存在很多误区。

 

经常遇到的疑问：微服务是用来解决什么问题的，或者能带来什么样收益？于是企业从各方面寻找可以优化的点，比如性能优化、资源节省、运维成本、管理难度，但是这一圈下来发现收益全部是负增长。性能由于加入检测探针，增加性能消耗；资源由于增加很多治理组件，增加资源消耗；运维和管理更是几何倍增长。因此，有些企业在建设一期的微服务平台之后，迁入或者甚至都没有迁入一个微服务系统的时候，就认为微服务化没有成果，从此中断。

 

另外，企业在做微服务化尝试的时候，通常都会拆分一个不是很关键的业务系统，以此来测试微服务化是否真的如互联网上炒得那么火热，那么有用。然而，这个很不关键的业务系统在尝试微服务化之后，企业会轻易地得出一些 “结论”：

 

    · 微服务的分布式似乎也没什么特别，反而带来了分布式的各种问题。

    · 微服务的限流熔断一般用不着，用了还有可能影响正常业务。

    · 微服务的观测也没啥用，如果不是出问题，平常根本没人看。

 

不仅是上面的两个理解误区，我们在做微服务类的项目时也遇到过很多比较有前瞻性的客户，但是完全按照客户的要求去建设的平台，却似乎不是很实用。等过两年之后，客户发现建设微服务还是很必要，于是总结之前的经验，觉得还是需要大厂来建设，因此只好花几倍的钱找大厂来做，而实际上再次建设可能还会遇到之前同样的问题，反而 “劳民伤财” 。其实主要原因还是没有把握住微服务的根本。

 

微服务解决的根本问题，总结一下其实是业务系统运行中由量变引起的一系列问题，量变引起质变，最终通过微服务的架构解决。如果业务访问量不够，那就不会用到限流熔断；如果应用服务数量不多，那就不需要统一管理和运行观测；如果服务变更不频繁，那也就不需要持续发布、灰度发布等。

 

微服务的优势在单一且没有业务量的系统中，完全不能发挥其长处，反而单体应用的优势更明显。这也正是微服务建设中最大的误区。

 

 

03 微服务治理平台的误区

 

当我们聊到微服务的时候，很多人第一印象就是拆分，一个拆成多个，这就是微服务。那么微服务治理、或者微服务运行平台，就是用来解决微服务拆成多个以后带来的问题。

 

具体问题有通信互访、流量保障、关系网络、运行状态、分布式事务、性能观测、故障定位、灰度发布等，很多方案都是由开源技术提供，比如微服务框架、APM 一些开源组件。

 

那么微服务治理平台就是开源组件的联合吗？在微服务治理中，开源组件有：

 

• 微服务框架（其实不属于组件）：在治理方面主要提供微服务的通信、负载均衡等，如 SpringCloud、Dubbo；

   

• 注册中心：提供服务注册发现机制，如 Nacos、Consul 等。

   

• 服务流量限制：通常有限流、熔断、降级等功能，如使用 Hystrix 组件。

   

• 配置中心：提供统一的配置管理，尤其是分布式服务下，服务配置的统一变更，如 Apollo。

   

• 服务观测：主要是 API 维度、服务维度的性能监控，服务间关系拓扑，链路追踪、日志追踪等功能，目前使用最多的是 Skywalking。

 

当然还有网关、分布式任务调度、分布式事务等组件，这些组件都是微服务运行所依赖的。

 

那这些组件的联合就可以做到微服务的治理了吗？其实微服务治理平台，主要还是管理，以业务视角的系统、应用的管理是治理平台最大的价值。注册中心提供的是全量的服务信息，配置中心也有全量的服务配置，但全都是技术角度的依赖工具，而不是管理工具。

 

我们刚刚提到微服务的量变引起的管理困难，在所有的开源工具中，都不能得到解决。无论是服务列表、服务配置、服务拓扑，我们要的不是技术角度的功能实现，而是业务角度的管理观测。开源的工具不是治理，如果立项，可别踩这坑。

 

综上所述，微服务化转型所有的误区，其实都是因为对微服务的认识不够和对微服务的规划不明确导致的。那么微服务化建设应该从哪些方面入手才是正确的建设方向，才能保证持续的进步，才能少踩坑，少走弯路？我们将在之后的文章中为大家分享正确的微服务转型的建设思路，敬请期待。