在之前文章中我们讲到企业的数字化转型（），通常两种技术的运用代表着数字化转型的实践，一种是容器技术，一种是微服务技术。容器技术的建设和使用都是运维，因此更容易快速上手和建设。但是，微服务技术就不同了，微服务架构的起点是研发，治理却在运维，架构反馈和改进又要回到研发（当然这是传统的企业管理模式下的），所以传统企业在微服务化建设时，会遇到很多微服务的相关问题和误区。
本文我们将对微服务化转型的常见误区进行了整理，并分享一些如何避开这些误区的建议和想法。
通常企业的数字化转型和系统的微服务化改造很容易被放在一起讨论，这样的说法是把微服务放到了一个系统级别，也就成为了一个部门或一个团队的任务。这其实就是一个企业刚开始做微服务转型的最大误区。
微服务化转型是企业级的改造工程，而具体的落实才是系统的改造，只关注于系统的微服务化改造，难免会“守一隅而遗万方”。其实，企业微服务化转型的很多误区都是这样产生的。
01 微服务拆分的误区
博云一直为企业提供微服务拆分的咨询服务，所以经常会接到微服务拆分的项目。有些客户通常只要咨询、只要方法论、只要单个系统拆分的服务，这样的方式其实都走入了微服务建设的误区。例如，我们之前遇到一个大企的微服务化转型项目，涉及近百个业务系统的微服务改造建设。面对这么大的微服务化建设，客户的想法却很简单，计划整体改造分成三步：
第一步：找一个对微服务拆分比较专业的公司，帮忙做第一个系统的拆分工作，并学习微服务拆分的精髓。
第二步：在咨询公司的帮助下，自行拆分二三十个业务系统，作为练兵。
第三步：摆脱咨询公司的帮助，拆分改造剩下的系统。
很明显，这是为了拆分而拆分。这样的建设相当于是单体应用系统平等地置换成微服务系统的应用，导致单体应用的优势没有了，而微服务的优势也并没有体现出来。可以预见，如果继续这样建设会出现很多麻烦：
业务系统由近百个变成近千个，完全颠覆了原来的管理模式。以前只需要在资源层面、网络层面的监控运维，而对于现在服务层面的观测简直束手无策。
如果只是单系统的考虑拆分，那么微服务带来的消耗是会增加的。微服务的拆分将一个运行程序拆成了十几个，还要依赖于必要的组件，如注册中心、配置中心、网关，当然每个都需要考虑高可用，那么在资源消耗上，将增加不止一倍的消耗，这样算来，整个企业的微服务改造，将可能会多改造出一个机房来。
刚刚提到监控运维，其实运维层面还有更多的问题。上百个系统，近千个服务，再加上分布式的部署方式，将有几千个运行程序的部署和升级迭代，这绝对不容小觑。
每个改造、建设，或者变革，都会被问到一个收益的问题，投入大量的人力、物力、财力，我们想要看到的是回报，而这种方式的拆分将只有投入。
微服务化转型，或者说微服务化建设，绝对不等于微服务的拆分。微服务的拆分仅针对于某一个系统，或者几个系统，跟架构师、研发人员比较密切相关。而微服务化的建设，其实针对的是整个企业的管理、运维，并关系到所有的微服务系统的研发和运维团队。所以企业在做微服务化转型的时候，我们应该把握微服务的优势，发挥其长处，弥补其不足。
不要把微服务建设，做成了微服务批量拆分，这是要注意的第一个误区。
02 微服务化建设的误区
谈到这里似乎应该说：“不要为了微服务而微服务”，但实际上为了微服务而建设微服务也不是问题，因为云原生理念与技术的普及已经如火如荼，所以熟悉相关技术也是势在必行。
很多企业看到了微服务的前景，也开始在架构、研发等部门中，建设一些微服务治理平台或者微服务运行观测平台，但是通常这类的试验性质的项目都存在很多误区。
经常遇到的疑问：微服务是用来解决什么问题的，或者能带来什么样收益？于是企业从各方面寻找可以优化的点，比如性能优化、资源节省、运维成本、管理难度，但是这一圈下来发现收益全部是负增长。性能由于加入检测探针，增加性能消耗；资源由于增加很多治理组件，增加资源消耗；运维和管理更是几何倍增长。因此，有些企业在建设一期的微服务平台之后，迁入或者甚至都没有迁入一个微服务系统的时候，就认为微服务化没有成果，从此中断。