Spring Cloud从构建到部署系列（一）之聊聊微服务

 既然要做微服务，当然要简单的聊聊什么是微服务，微服务的优缺点等等，当然网上会有很多类似的文章，我这里只谈谈我对微服务的理解。

首先，什么是微服务？

“微服务”一词源于Martin Fowler大叔的一篇名为Microservices的文章，有兴趣的小伙伴可以去看看。用马丁大叔的一段话来概括就是：

 

   简而言之，微服务架构风格是一种将单个应用程序作为一套小型服务开发的方法，每种应用程序都在自己的进程中运行，并与轻量级机制（通常是HTTP资源API）进行通信。 这些服务是围绕业务功能构建的，可以通过全自动部署机制独立部署。 这些服务的集中管理最少，可以用不同的编程语言编写，并使用不同的数据存储技术。

    可能小伙伴们看到这也是一脸懵13，我的理解是，简单的说，微服务是几年来流行起来的一种架构思想，将我们传统的单体架构应用，根据业务逻辑以及业务耦合度进行拆分成为多个小服务，每个服务之间独立开发，独立部署，彼此之间进程隔离，通过Rest API进行通信。由于服务与服务之间是彼此独立的，因而可以根据自己的业务需求，采用不同的开发语言，使用不同的数据库。说了这么多，为什么要选择微服务？微服务有哪些优点？我们就先聊聊传统单体架构应用的问题。

• 1.项目太过臃肿

       所有的代码都集中于一个项目中， 而且随着业务的拓展，项目会越来约臃肿，变得难以维护。再有如果项目过大，调试也会变得艰难，比如我之前就接触过一个项目，上百个业务模块都在一起，每次开发完成，调试的时候，启动需要半个小时，只能去喝喝咖啡，刷刷网页，而且调试的过程中会伴随频繁的重启，这种情况基本重启个几次就下班了。下班？不可能的！

• 2.无法做到资源隔离

        因为所有的业务都在一个项目中，所以所有的资源基本都是共享的，比如数据库，如果其中某个模块的bug造成对数据库的使用不当，整个项目全都GG了。如果这个功能恰好是你开发的，那么。。。。。

• 3.无法灵活扩展

        当应用的访问量越来越来大的时候，系统的压力就会非常大，虽然可以横向扩展，构建集群，但是不够灵活。为啥这么说呢，因为不会应用中的所有模块的访问量都增加，就以某宝为例，大多数人买东西都是看来看去，但是真正买的却很少，所以商品列表模块的访问量会远远大于支付模块，为了应对商品模块的高访问量，不得不将其他模块一起横向扩展,其他模块表示很不开心。

接下来针对传统单体架构应用的问题来说说微服务的好处:

• 1.独立开发，独立部署，拓展灵活

    相对于单体架构，微服务以模块划分成多个服务，每个服务独立开发，独立部署，服务之间采用REST通信。拓展灵活，可以针对不同模块定制拓展计划。

   另外一个服务的故障或者升级，对其他服务没有影响。相比于单体应用升级一个功能所有业务模块都无法使用，是一个非常大的改善。

• 2.资源隔离

    每个模块都是独立部署的，每个服务都有独立的数据源，此外微服务采用容器化部署，如docker，可以实现服务器资源隔离。    

通过微服务与传统单体架构的对比不难发现微服务的优势，但是微服务架构也存在一些问题和挑战：

•    运维

        运维人员维护的进程数量会大大增加，将这些服务合理的编排起来不是一件容易的事情，这就需要运维人员掌握更多的自动化技术

• 接口的一致性

        虽然拆分成了单独的服务，但是业务逻辑上的依赖并未消除，只是从单体应用中的代码依赖改为了服务之间的通信依赖。如果我们对原有的接口做出了修改，那么调用方也需要做出相应的改变，才能保证接口的正确调用

• 分布式的复杂度

        由于服务的拆分，每个服务都是独立部署，运行在独立的进程中，服务之间只能靠通信来进行协作，所以分布式的问题都将是微服务架构需要考虑的问题，例如网络延迟，分布式事务，异步消息等。

    上面通过单体应用和微服务的对比，简单的说明了微服务的优势和存在的问题，当然还有一些其他的问题需要去考虑，例如架构的设计成本，一个好的架构不是设计出来的，而是通过演进而来，也不是所有的应用都适用微服务，应该结合应用本身的价值与目的选择最优的方案。

    好了，简单的聊了聊微服务，那么如何去实现微服务？微服务只是一种架构思想，理解了思想，接下来就是选择合适的技术去实现微服务的架构，接下来我会介绍基于spring cloud来实现微服务，为啥要选择spring cloud呢？原因很简单，spring大家都是知道的，在java开发中的地位是显而易见的，无论它强大的背景，还是社区的活跃度，都是值得我们去信赖的。当然对于已经对微服务实施自成体系并且趋近成熟的团队来说可能不具备吸引力，但是对于想要尝试微服务架构的团队或个人来讲，spring cloud都是不二之选。