我们真的需要微服务吗？

什么是微服务？

微服务是很小的，但是又能够独立部署的服务。

微服务的优点

1.不同的服务可以使用不同的语言和技术来实现

2.提供服务可用性，当其中一个服务不能正常工作，可以通过多实例或者服务降级来维持着

3.扩展性好，某些特别需要资源的服务可以专门提供更多的资源来支撑

4.部署简单，如果是单体应用，修改一行代码都需要整个工程重启

5.因为微服务的每个服务都很小，所以修改起来十分轻松，并且重构都是简简单单的事情

微服务的缺点

1.技术门槛提高了，因为你要面对分布式的问题

2.总体部署也变得复杂了，因为你多个服务可能需要不同的环境，你还要为其提供必需的运行环境

3.需要考虑服务间通讯的可靠性和稳定性，网络并不是十分可靠的

4.服务数量一多，如果依赖错综复杂的话，绝对是一个灾难

尝试微服务

如果你看了上面的缺点，觉得启用微服务的好处大于缺点的话，可以尝试开始微服务。在决定开始微服务之前，首先先好好考虑一下自己的技术团队有没有下面提及的能力。

1. 有一定的运维能力，最不济也会写shell脚本半自动部署
2. 有一定的架构能力，不然如何拆分成一个又一个的服务，服务拆分边界的定义可是一件技术活
3. 有足够的人力（上微服务的前期投入肯定比不使用微服务大）

如果看到这里，依旧觉得微服务还是必须的话，那么，我必须先跟你说一下我亲身经历过微服务导致的事故，当然不是说我不提倡用微服务，而是尽可能告知一下使用微服务可能遇到的问题。

微服务带来的事故

当时年少无知，初听到微服务，觉得这是一种高大上的开发技术，并且持着自己会docker，会折腾一下k8s，所以果断把一个项目拆成若干个服务。

真别说，一开始开发的时候，一个同学只需要2，3天独立写完一个服务。因为用docker部署，所以我准备好各种环境的镜像即可，然后通过k8s编排应用，有自己的CI管理应用（这个CI经过半年断断续续的迭代，正准备开源出来），部署也是一分钟解决了。那成就感刷刷刷的就上去，但是好景不长呀。

第一次事故出现在集群身上，镜像没优化好，服务扩充得太快，日志收集没做，直接导致服务可用性还比不上以前，线上查错也复杂了。好不容易，把这些都优化了，但是问题才陆续有来。（基于docker的部署，小心磁盘不够用和妥善收集日志）

第二次事故出现在服务之间的通讯上，基于http的试了，基于rabbitmq的试了。也许你会说，这有什么问题呀。第一个，服务间的通讯导致代码量增加了，那么意味着我们的同学要写更多的代码了。工作量还是其中一个问题，不同环境还要调用不同环境里面的服务。本地开发如何调用其它服务呢？（值得思考的问题）

事故还没完，当你做ABtest的时候，做灰度发布的时候，调用链有几层的时候，如何处理？自己实现，直接蒙圈。用现成的，上服务注册中心，这是技术门槛嗖嗖嗖的上去了，小团队真心折腾不起来。

经历微服务事故之后的感想

以前的我，喜欢用shell实现半自动化部署。只从经历了一次微服务模式的应用开发之后，我喜欢上CI了（为什么我自己造一个CI，因为我没发现哪个CI可以简简单单的用，又能随时回退到任意版本）。

发布不中断服务，只需要滚动发布就好了，k8s和docker swarm一个服务多个实例，选择正确的更新模式。

docker真是一个好玩意，每个版本一个镜像，想回滚就回滚（但是回滚风险自行考虑）。

开始你的微服务之旅

我上面说了这么多唬人的话，你是不是有点想放弃微服务呢？不，不能如此想。现在我用我短短的微服务开发经验来谈论一下，其实每个人都可以使用微服务的架构设计。

首先，还是按着以前的模式开发。但是一些不会经常变化的，又是公司层面或者团队层面公用的服务抽离出来。例如发送短信，邮件服务，用户登录服务。

接着，是不是发现支付系统，应用消息推送系统也可以拆出来，成为一个微服务呢？

把基础服务都拆成微服务之后，是不是意犹未尽，还想拆拆拆。别慌，满足你。这个时候，你可以根据业务为边界拆分，只要你拆出来的服务仅仅是给其它服务调用，不依赖其它服务，你就可以勇敢的拆。

当你拆的服务越多，你的运维压力就越大，记得多使用工具和找厉害的运维提供必要的技术支持。另外我听来的一个观点是，一个微服务，你能2星期内重构掉，大小才是合理的。

写在最后

别想着看完这文章，你就可以在微服务领域为所欲为。看完，有所感悟就好。没有收获，也别吐槽我。

如果你想你的团队hold住微服务架构，那么请先聘请一个技术过硬的技术人员和经验丰富的架构师来设计开发。

我准备开源我自己在用的CI出来，但是呢，还有一些优化的点还没处理好，请耐心等待。我的GitHub地址是： https://github.com/yubang