共计 3088 个字符，预计需要花费 8 分钟才能阅读完成。
导读
本篇文章为博云微服务转型系列第二篇文章。
在之前文章中咱们讲到企业的数字化转型（详情回顾：农商行数字化转型的懊恼），通常两种技术的使用代表着数字化转型的实际，一种是容器技术，一种是微服务技术。容器技术的建设和应用都是运维，因而更容易疾速上手和建设。然而，微服务技术就不同了，微服务架构的终点是研发，治理却在运维，架构反馈和改良又要回到研发（当然这是传统的企业管理模式下的），所以传统企业在微服务化建设时，会遇到很多微服务的相干问题和误区。
本文咱们将对微服务化转型的常见误区进行了整顿，并分享一些如何避开这些误区的倡议和想法。
通常企业的数字化转型和零碎的微服务化革新很容易被放在一起探讨，这样的说法是把微服务放到了一个零碎级别，也就成为了一个部门或一个团队的工作。这其实就是一个企业刚开始做微服务转型的最大误区。
微服务化转型是企业级的革新工程，而具体的落实才是零碎的革新，只关注于零碎的微服务化革新，难免会“守一隅而遗万方”。其实，企业微服务化转型的很多误区都是这样产生的。
01 微服务拆分的误区
博云始终为企业提供微服务拆分的咨询服务，所以常常会接到微服务拆分的我的项目。有些客户通常只有征询、只有方法论、只有单个零碎拆分的服务，这样的形式其实都走入了微服务建设的误区。例如，咱们之前遇到一个大企的微服务化转型我的项目，波及近百个业务零碎的微服务革新建设。面对这么大的微服务化建设，客户的想法却很简略，打算整体革新分成三步：
第一步：找一个对微服务拆分比拟业余的公司，帮忙做第一个零碎的拆分工作，并学习微服务拆分的精华。
第二步：在征询公司的帮忙下，自行拆分二三十个业务零碎，作为练兵。
第三步：解脱征询公司的帮忙，拆分革新剩下的零碎。
很显著，这是为了拆分而拆分。这样的建设相当于是单体利用零碎平等地置换成微服务零碎的利用，导致单体利用的劣势没有了，而微服务的劣势也并没有体现进去。能够预感，如果持续这样建设会呈现很多麻烦：
业务零碎由近百个变成近千个，齐全颠覆了原来的管理模式。以前只须要在资源层面、网络层面的监控运维，而对于当初服务层面的观测几乎大刀阔斧。
如果只是单零碎的思考拆分，那么微服务带来的耗费是会减少的。微服务的拆分将一个运行程序拆成了十几个，还要依赖于必要的组件，如注册核心、配置核心、网关，当然每个都须要思考高可用，那么在资源耗费上，将减少不止一倍的耗费，这样算来，整个企业的微服务革新，将可能会多革新出一个机房来。
刚刚提到监控运维，其实运维层面还有更多的问题。上百个零碎，近千个服务，再加上分布式的部署形式，将有几千个运行程序的部署和降级迭代，这相对不容小觑。
每个革新、建设，或者改革，都会被问到一个收益的问题，投入大量的人力、物力、财力，咱们想要看到的是回报，而这种形式的拆分将只有投入。
微服务化转型，或者说微服务化建设，相对不等于微服务的拆分。微服务的拆分仅针对于某一个零碎，或者几个零碎，跟架构师、研发人员比拟密切相关。而微服务化的建设，其实针对的是整个企业的治理、运维，并关系到所有的微服务零碎的研发和运维团队。所以企业在做微服务化转型的时候，咱们应该把握微服务的劣势，施展其短处，补救其有余。
不要把微服务建设，做成了微服务批量拆分，这是要留神的第一个误区。
02 微服务化建设的误区
谈到这里仿佛应该说：“不要为了微服务而微服务”，但实际上为了微服务而建设微服务也不是问题，因为云原生理念与技术的遍及曾经热火朝天，所以相熟相干技术也是势在必行。
很多企业看到了微服务的前景，也开始在架构、研发等部门中，建设一些微服务治理平台或者微服务运行观测平台，然而通常这类的试验性质的我的项目都存在很多误区。
常常遇到的疑难：微服务是用来解决什么问题的，或者能带来什么样收益？于是企业从各方面寻找能够优化的点，比方性能优化、资源节俭、运维老本、治理难度，然而这一圈下来发现收益全副是负增长。性能因为退出检测探针，减少性能耗费；资源因为减少很多治理组件，减少资源耗费；运维和治理更是几何倍增长。因而，有些企业在建设一期的微服务平台之后，迁入或者甚至都没有迁入一个微服务零碎的时候，就认为微服务化没有成绩，从此中断。
另外，企业在做微服务化尝试的时候，通常都会拆分一个不是很要害的业务零碎，以此来测试微服务化是否真的如互联网上炒得那么炽热，那么有用。然而，这个很不要害的业务零碎在尝试微服务化之后，企业会轻易地得出一些“论断”：
· 微服务的分布式仿佛也没什么特地，反而带来了分布式的各种问题。· 微服务的限流熔断个别用不着，用了还有可能影响失常业务。· 微服务的观测也没啥用，如果不是出问题，平时基本没人看。不仅是下面的两个了解误区，咱们在做微服务类的我的项目时也遇到过很多比拟有前瞻性的客户，然而齐全依照客户的要求去建设的平台，却仿佛不是很实用。等过两年之后，客户发现建设微服务还是很必要，于是总结之前的教训，感觉还是须要大厂来建设，因而只好花几倍的钱找大厂来做，而实际上再次建设可能还会遇到之前同样的问题，反而“劳民伤财”。其实次要起因还是没有把握住微服务的基本。
微服务解决的基本问题，总结一下其实是业务零碎运行中由质变引起的一系列问题，质变引起量变，最终通过微服务的架构解决。如果业务访问量不够，那就不会用到限流熔断；如果应用服务数量不多，那就不须要对立治理和运行观测；如果服务变更不频繁，那也就不须要继续公布、灰度公布等。
微服务的劣势在繁多且没有业务量的零碎中，齐全不能施展其短处，反而单体利用的劣势更显著。这也正是微服务建设中最大的误区。
03 微服务治理平台的误区
当咱们聊到微服务的时候，很多人第一印象就是拆分，一个拆成多个，这就是微服务。那么微服务治理、或者微服务运行平台，就是用来解决微服务拆成多个当前带来的问题。
具体问题有通信互访、流量保障、关系网络、运行状态、分布式事务、性能观测、故障定位、灰度公布等，很多计划都是由开源技术提供，比方微服务框架、APM 一些开源组件。
那么微服务治理平台就是开源组件的联结吗？在微服务治理中，开源组件有：
- 微服务框架（其实不属于组件）：在治理方面次要提供微服务的通信、负载平衡等，如 SpringCloud、Dubbo；
- 注册核心：提供服务注册发现机制，如 Nacos、Consul 等。
- 服务流量限度：通常无限流、熔断、降级等性能，如应用 Hystrix 组件。
- 配置核心：提供对立的配置管理，尤其是分布式服务下，服务配置的对立变更，如 Apollo。
- 服务观测：次要是 API 维度、服务维度的性能监控，服务间关系拓扑，链路追踪、日志追踪等性能，目前应用最多的是 Skywalking。
当然还有网关、分布式任务调度、分布式事务等组件，这些组件都是微服务运行所依赖的。
那这些组件的联结就能够做到微服务的治理了吗？其实微服务治理平台，次要还是治理，以业务视角的零碎、利用的治理是治理平台最大的价值。注册核心提供的是全量的服务信息，配置核心也有全量的服务配置，但全都是技术角度的依赖工具，而不是管理工具。
咱们刚刚提到微服务的质变引起的治理艰难，在所有的开源工具中，都不能失去解决。无论是服务列表、服务配置、服务拓扑，咱们要的不是技术角度的性能实现，而是业务角度的治理观测。开源的工具不是治理，如果立项，可别踩这坑。
综上所述，微服务化转型所有的误区，其实都是因为对微服务的意识不够和对微服务的布局不明确导致的。那么微服务化建设应该从哪些方面动手才是正确的建设方向，能力保障继续的提高，能力少踩坑，少走弯路？咱们将在之后的文章中为大家分享正确的微服务转型的建设思路，敬请期待。
