微服务的概念什么是微服务？网上有很多文章。看完之后似懂非懂。理论论证太多，不如实践经验真实。我在工作中实践的所谓“微服务”，就是将业务拆分，模块化，拆分成一个个服务。从这个角度看，并不能体现“微”，因为即使拆分之后，一些服务也会随着业务的增长逐渐“大”起来。让我称之为“多服务”。多服务的痛点开发和发布原始微服务的思路是模块化开发，互不干扰。但是因为我们每个端都有一个shell服务（在我们的架构中，就是直接连接前端的服务，也有人叫这个网关）。结果每次开发至少涉及两个服务，一个是模块化的基础服务，一个是“壳”服务，甚至三个。这会导致一个业务的发展，可能需要编写两三个服务代码。发布还需要发布两个或三个服务。回滚也是如此。如果你开发的服务中有你的同事同时上线的代码，回滚起来会很痛苦（当然，这种事情应该是零发生，但也不能绝对避免）。线上问题排查由于一个接口的调用链可能达到3、4层，导致问题排查效率低下，定位修复速度不够快，影响用户体验。流量问题有一种情况是很多服务都依赖同一个服务，导致该服务的流量非常大。你经常看到502在线，socket挂掉等等，各种以前没遇到过的网络问题。.虽然暂时找不到根源，但是这些奇怪的问题都是在流量上来之后才出现的，这是显而易见的事实。服务管理和维护我们的微服务部署在docker集群中。由于对docker的使用和理解不够深入，出现问题不能迅速解决，影响业务。总结就是技术不行，微服务的实践肯定会遇到麻烦的问题。也许微服务最重要的一点就是业务的划分。微服务需要改进的地方有很多，远高于维护通用服务的要求。
