另外，企业在做微服务化尝试的时候，通常都会拆分一个不是很关键的业务系统，以此来测试微服务化是否真的如互联网上炒得那么火热，那么有用。然而，这个很不关键的业务系统在尝试微服务化之后，企业会轻易地得出一些 “结论”：
· 微服务的分布式似乎也没什么特别，反而带来了分布式的各种问题。
· 微服务的限流熔断一般用不着，用了还有可能影响正常业务。
· 微服务的观测也没啥用，如果不是出问题，平常根本没人看。
不仅是上面的两个理解误区，我们在做微服务类的项目时也遇到过很多比较有前瞻性的客户，但是完全按照客户的要求去建设的平台，却似乎不是很实用。等过两年之后，客户发现建设微服务还是很必要，于是总结之前的经验，觉得还是需要大厂来建设，因此只好花几倍的钱找大厂来做，而实际上再次建设可能还会遇到之前同样的问题，反而 “劳民伤财” 。其实主要原因还是没有把握住微服务的根本。
微服务解决的根本问题，总结一下其实是业务系统运行中由量变引起的一系列问题，量变引起质变，最终通过微服务的架构解决。如果业务访问量不够，那就不会用到限流熔断；如果应用服务数量不多，那就不需要统一管理和运行观测；如果服务变更不频繁，那也就不需要持续发布、灰度发布等。
微服务的优势在单一且没有业务量的系统中，完全不能发挥其长处，反而单体应用的优势更明显。这也正是微服务建设中最大的误区。
03 微服务治理平台的误区
当我们聊到微服务的时候，很多人第一印象就是拆分，一个拆成多个，这就是微服务。那么微服务治理、或者微服务运行平台，就是用来解决微服务拆成多个以后带来的问题。
具体问题有通信互访、流量保障、关系网络、运行状态、分布式事务、性能观测、故障定位、灰度发布等，很多方案都是由开源技术提供，比如微服务框架、APM 一些开源组件。
那么微服务治理平台就是开源组件的联合吗？在微服务治理中，开源组件有：
微服务框架（其实不属于组件）：在治理方面主要提供微服务的通信、负载均衡等，如 SpringCloud、Dubbo；
注册中心：提供服务注册发现机制，如 Nacos、Consul 等。
服务流量限制：通常有限流、熔断、降级等功能，如使用 Hystrix 组件。
配置中心：提供统一的配置管理，尤其是分布式服务下，服务配置的统一变更，如 Apollo。
服务观测：主要是 API 维度、服务维度的性能监控，服务间关系拓扑，链路追踪、日志追踪等功能，目前使用最多的是 Skywalking。
当然还有网关、分布式任务调度、分布式事务等组件，这些组件都是微服务运行所依赖的。
那这些组件的联合就可以做到微服务的治理了吗？其实微服务治理平台，主要还是管理，以业务视角的系统、应用的管理是治理平台最大的价值。注册中心提供的是全量的服务信息，配置中心也有全量的服务配置，但全都是技术角度的依赖工具，而不是管理工具。
我们刚刚提到微服务的量变引起的管理困难，在所有的开源工具中，都不能得到解决。无论是服务列表、服务配置、服务拓扑，我们要的不是技术角度的功能实现，而是业务角度的管理观测。开源的工具不是治理，如果立项，可别踩这坑。
综上所述，微服务化转型所有的误区，其实都是因为对微服务的认识不够和对微服务的规划不明确导致的。那么微服务化建设应该从哪些方面入手才是正确的建设方向，才能保证持续的进步，才能少踩坑，少走弯路？我们将在之后的文章中为大家分享正确的微服务转型的建设思路，敬请期待。