究竟是否应该使用“微服务架构”？

前言

通过当前服务端的洗礼以后，市场出现了一波微服务的热潮。而后就出现了很大的一个问题，不管什么项目，不少人想都不想，都直接开始说咱们使用微服务架构来完成吧，用这个、这个组件很简单就能实现。。。并且，如今市场上不少学习教程都直接教授微服务的架构使用。不少学习的人看到这样的趋势就会随大流，就致使了当前的问题，炒做这样概念的人不少，不多人知其因此然。

通过一段时间的整理，梳理出了下面几个点，可供参考。

但愿通过这些简短的参考能帮助你认识，技术的因此然。

 

什么是“微服务架构”

官方：一种将一个单一应用程序开发为一组小型服务的方法，每一个服务运行在本身的进程中，服务间通讯采用轻量级通讯机制。这些服务围绕业务能力构建而且能够独立部署。依赖一个最小型的集中式管理。

总结为几点：

一、独立运行

二、独立部署

三、独立开发

四、轻量级通讯

五、集中管理

这样说仍是有点抽象，举个实际的例子来讲，好比购物：咱们能够拆分为，用户微服务，订单微服务，商品微服务…..

每一个服务都有以上特色，之间独立，又能够通讯，依赖一些管理的东西去管理他们。

中心思想：把大系统拆分红小型系统，把大事化小，以下降系统的复杂性

 

“微服务架构”的优势和缺点

若是只是说一个东西的优势是没用的，只有对比来看，因此咱们对比单体应用来讲明其优势。

一、部署：

单体应用部署确定简单，一个包扔进去，容器启动就能够了。

微服务应用部署会负责，服务越多部署越麻烦，并且有些依赖与一些中间件，因此运维和部署的压力变大是确定的。（这里并非说必定的，已经有一些运维部署的软件方便了微服务的部署）

二、开发和维护：

单体应用若是要进行开发，代码即便分离的再好，那么仍是在一块儿，因此会显得臃肿，维护起来不方便，若是须要改动一个点，整个服务必须所有从新启动。

微服务开发由于自己分离，因此显得清晰，维护起来方便，一个地方的服务出现问题，只须要改动对应服务并重启对应服务便可。

三、扩展：

单体应用扩展可想而知，受限而且压力很大，到最后不少人会发现，加入或者扩展功能时宁肯新开发一个也不肯意去依赖原来的代码就怕改了原来的代码以前的代码出现问题。

微服务扩展能力较好，新加入一个功能不会对原来的系统形成影响。并且若是一个大的功能被禁用，直接中止对应服务便可。

四、通讯：

对于单体应用来讲，本身自己都是内部服务调用不存在通讯问题，对于外部库来讲，通讯方式取决于外部库的依赖。

微服务之间的通讯就须要依赖比较靠谱的通讯系统了，由于不免服务与服务之间会有依赖，那么通讯方式的选择就尤其重要了。

 

究竟是否应该使用“微服务架构”？

最后咱们再来看看咱们一开始的问题，是否是就能总结出如下几个点了。而后我结合一些书本和经验作下面一个总结，但愿对你有帮助。

一、系统大小

这是咱们首要的考虑目标，若是一个系统很小，好比一个官网，那你说作微服务就是扯淡了。那么如何肯定一个系统的大小呢？能够参考一下下面这个标准。

若是你的项目能分红三个或三个以上的耦合度很低的项目，那么就算大。

若是你的项目数据库表超过30张，且单表数据轻松百万，那么就算大。

若是你的项目以后会进行扩展，而且扩展以后会达到上面的若是，那么也算大。

虽然只是经验上的估计参考，可是也从侧面体现出，若是项目不大，那么真的就不必。

 

二、技术能力

微服务依赖的能力有如下几点

拆分服务的能力

处理分布式问题（网络请求，分布式事务等）的能力

强大的运维能力

若是一个系统决定使用微服务架构，那么前期的拆分就显得很是重要，有经验的拆分可让服务之间的耦合对降到最低，而且相应的业务没有问题。相应的，若是没有处理分布式问题的能力也是不行的，最后才是项目部署运维的能力。

 

三、团队规模和时间

若是你的团队规模不超过10人，那么除非大家能力都很是牛，并且都能独当一面，那么当我没说，理论上不建议。

在开发周期时间不容许的状况下不要执意去切换，从单体切换到微服务，由于二者区别不只仅是在服务上，包括通讯等等方面耗时都不短，测试上面就须要更加多的时间去测试。并且微服务的开发效率上面是一开始慢，到项目大了以后开发效率才慢慢的体现出来。

微服务毕竟存在通讯，并且服务器想对多，项目稳定性上确定要打折扣。你的团队须要提早了解到这样的问题，并作好遇到问题的准备和处理，这也是须要时间的。

团队之间的沟通，有通讯必然有交流，否则别人怎么知道你的服务是怎么样的。那么接口文档编写的时间和对接接口的时间，调试的时间，剩下我就很少说了，你应该懂了。

 

总结

一个技术或者一个架构不是万能的，每一个技术都有适用的场景，咱们所要作的不是一味的追求最新，而是明白它的使用场景或者优势缺点，从而来考虑是否使用。

这里上面也只是抛砖引玉，全部的细节确定不是一篇文章或者一本书能说完的，只要你去考虑了，借鉴一些别人的经验去发现可能存在的问题，那么即便最后出现问题也能够被解决。

 

参考文档：

《SpringCloud与Docker微服务架构实战》

http://www.infoq.com/cn/minibooks/microservice--from-zero