微服务的概念
什么是微服务？网上有很多文章，看完之后似懂非懂，理论上扯太多，不如实践体会的真实。以我工作中实践的所谓“微服务”，就是把业务进行拆分，模块化，独立成一个个的服务。这样来看并不能体现出“微”来，因为即使进行了拆分，有些服务还是会随着业务的增长逐渐变“大”。我姑且叫它“多服务”吧。
多服务的痛点
开发和发布
原本微服务的想法是模块化开发，互不干扰。但是由于我们有针对每个端都有一个壳子服务（在我们的架构中是直接对接前端的那个服务，也有人称这个为 gateway）。导致每次开发至少会涉及到两个服务，一个是模块化的基础服务，一个是“壳子”服务，甚至是三个。这样就会导致一次业务的开发，可能需要编写两三个服务的代码。发布也需要发布两三个服务。回滚也一样。如果你开发的服务中同时存在同事上线的代码，回滚起来就是一件很蛋疼的事情（当然，这种事情应该做到 0 发生，但也无法绝对避免）。
线上问题排查
由于一个接口的调用链可能达到 3 层或 4 层，导致问题的排查低效，定位和修复的速度不够快，影响用户体验。
流量问题
有一种情况是，很多服务都依赖于同一个服务，导致该服务的流量非常的大，常常会看到线上有 502、socket hang up 等，各种之前从没有碰到过的网络问题。虽然暂时无法排查到根本的原因，但一个明显的事实是流量上来之后才出现这些奇怪的问题。
服务的管理和维护
我们的微服务是部署在 docker 集群的，由于对 docker 的使用和理解不够深入，导致出现问题的时候无法快速解决，从而影响了业务。
总结
技术不够，实践微服务一定是会遇到麻烦的问题的。
微服务可能最重要的一点是业务的划分吧。
微服务需要完善的东西很多，比维护一般的服务要求高很多。