前言
经过当前服务端的洗礼之后，市场出现了一波微服务的热潮。然后就出现了很大的一个问题，无论什么项目，很多人想都不想，都直接开始说我们使用微服务架构来完成吧，用这个、这个组件很简单就能实现。。。而且，现在市场上很多学习教程都直接教授微服务的架构使用。很多学习的人看到这样的趋势就会随大流，就导致了当前的问题，炒作这样概念的人很多，很少人知其所以然。
经过一段时间的整理，梳理出了下面几个点，可供参考。
希望经过这些简短的参考能帮助你认识，技术的所以然。
什么是“微服务架构”
官方：一种将一个单一应用程序开发为一组小型服务的方法，每个服务运行在自己的进程中，服务间通信采用轻量级通信机制。这些服务围绕业务能力构建并且可以独立部署。依赖一个最小型的集中式管理。
总结为几点：
1、独立运行
2、独立部署
3、独立开发
4、轻量级通信
5、集中管理
这样说还是有点抽象，举个实际的例子来说，比如购物：我们可以拆分为，用户微服务，订单微服务，商品微服务…..
每个服务都有以上特点，之间独立，又可以通信，依赖一些管理的东西去管理他们。
中心思想：把大系统拆分成小型系统，把大事化小，以降低系统的复杂性
“微服务架构”的优点和缺点
如果只是说一个东西的优点是没用的，只有对比来看，所以我们对比单体应用来说明其优点。
1、部署：
单体应用部署肯定简单，一个包扔进去，容器启动就可以了。
微服务应用部署会负责，服务越多部署越麻烦，而且有些依赖与一些中间件，所以运维和部署的压力变大是肯定的。（这里并不是说一定的，已经有一些运维部署的软件方便了微服务的部署）
2、开发和维护：
单体应用如果要进行开发，代码即使分离的再好，那么还是在一起，所以会显得臃肿，维护起来不方便，如果需要改动一个点，整个服务必须全部重新启动。
微服务开发因为本身分离，所以显得清晰，维护起来方便，一个地方的服务出现问题，只需要改动对应服务并重启对应服务即可。
3、扩展：
单体应用扩展可想而知，受限并且压力很大，到最后很多人会发现，加入或者扩展功能时宁可新开发一个也不愿意去依赖原来的代码就怕改了原来的代码之前的代码出现问题。
微服务扩展能力较好，新加入一个功能不会对原来的系统造成影响。而且如果一个大的功能被禁用，直接停止对应服务即可。
4、通信：
对于单体应用来说，自己本身都是内部服务调用不存在通信问题，对于外部库来说，通信方式取决于外部库的依赖。
微服务之间的通信就需要依赖比较靠谱的通信系统了，因为难免服务与服务之间会有依赖，那么通信方式的选择就尤为重要了。
到底是否应该使用“微服务架构”？
最后我们再来看看我们一开始的问题，是不是就能总结出以下几个点了。然后我结合一些书本和经验做下面一个总结，希望对你有帮助。
1、系统大小
这是我们首要的考虑目标，如果一个系统很小，比如一个官网，那你说做微服务就是扯淡了。那么如何确定一个系统的大小呢？可以参考一下下面这个标准。
如果你的项目能分成三个或三个以上的耦合度很低的项目，那么就算大。
如果你的项目数据库表超过30张，且单表数据轻松百万，那么就算大。
如果你的项目之后会进行扩展，并且扩展之后会达到上面的如果，那么也算大。
虽然只是经验上的估计参考，但是也从侧面体现出，如果项目不大，那么真的就没必要。
2、技术能力
微服务依赖的能力有以下几点
拆分服务的能力
处理分布式问题（网络请求，分布式事务等）的能力
强大的运维能力
如果一个系统决定使用微服务架构，那么前期的拆分就显得非常重要，有经验的拆分可以让服务之间的耦合对降到最低，并且相应的业务没有问题。相应的，如果没有处理分布式问题的能力也是不行的，最后才是项目部署运维的能力。
3、团队规模和时间
如果你的团队规模不超过10人，那么除非你们能力都非常牛，而且都能独当一面，那么当我没说，理论上不建议。
在开发周期时间不允许的情况下不要执意去切换，从单体切换到微服务，因为两者区别不仅仅是在服务上，包括通信等等方面耗时都不短，测试上面就需要更加多的时间去测试。而且微服务的开发效率上面是一开始慢，到项目大了之后开发效率才慢慢的体现出来。
微服务毕竟存在通信，而且服务器想对多，项目稳定性上肯定要打折扣。你的团队需要提前了解到这样的问题，并做好遇到问题的准备和处理，这也是需要时间的。
团队之间的沟通，有通信必然有交流，不然别人怎么知道你的服务是怎么样的。那么接口文档编写的时间和对接接口的时间，调试的时间，剩下我就不多说了，你应该懂了。
总结
一个技术或者一个架构不是万能的，每个技术都有适用的场景，我们所要做的不是一味的追求最新，而是明白它的使用场景或者优点缺点，从而来考虑是否使用。
这里上面也只是抛砖引玉，所有的细节肯定不是一篇文章或者一本书能说完的，只要你去考虑了，借鉴一些别人的经验去发现可能存在的问题，那么即使最后出现问题也可以被解决。
参考文档：
《SpringCloud与Docker微服务架构实战》