微服务架构详解程序员

一、前言

        ”微服务“架构是近期以来软件应用领域最热门的概念。那什么是”微服务“？”微服务“又跟我们传统的架构有什么区别呢？”微服务“能用来做什么？

二、什么是”微服务“

         ”微服务“是一种架构风格，就是把一个大型的(复杂的)单个应用程序和服务拆分为一个乃至多个的微服务。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。每个任务代表着一个小的业务能力。”微服务“一定要区别于系统，”微服务“是服务于一个或者一组相对较小且独立的功能单元，是用户可以感知的最小功能集。每一个功能元素最终都是一个可独立替换和独立升级的软件单元。

   其实，”微服务“的本质就是将复杂的服务拆分成单独的个体，个体之间通过统一的HTTP协议相互沟通的一个过程。

   如果把计算机比作一个高效的车辆交通网络的话，微服务就是将每一台车辆（服务）当作一个单独的个体，车辆（服务）和车辆（服务）之间相互联网沟通，最终达到一个服务目标的整体。

三、”微服务“的由来

          ”微服务“最早由Martin Fowler与James Lewis于2014年共同提出，微服务架构风格是一种使用一套小服务来开发单个应用的方式途径，每个服务运行在自己的进程中，并使用轻量级机制通信，通常是HTTP API，这些服务基于业务能力构建，并能够通过自动化部署机制来独立部署，这些服务使用不同的编程语言实现，以及不同数据存储技术，并保持最低限度的集中式管理。

四、”微服务“能用来做什么

          ”微服务“并不是一个突然兴起的概念，其本质上还是在传统服务架构上进行演进的一个过程。微服务和其他架构不同的地方在于在过去的软件架构中，服务往往作为一个整体来为统一的目标提供业务上的支持，但是微服务不同，微服务是通过API模式进行，所以微服务更加偏近于编程的后端部分。而且微服务可以将业务进行拆分，这样在设计很多细节的问题的时候，服务和服务之间的耦合度会非常的小，每个服务都能实现自动测试，自动治理，自动运维。使得计算机后端的业务能力得到飞速的提升。     

          但是微服务不是解决一切问题的“银弹”，在计算机的技术里面，没有什么技术可以解决一切的问题，微服务也是这样。任何问题都要辩证的去看待和实现，微服务也是这样。所以灵活运用，不断创新这才是计算机任何技术真正的内部含义。

五、传统系统架构与微服务架构的区别

         【传统的系统架构】是单一架构模式。这种架构模式就是把应用整体打包部署，具体的样式依赖本身应用采用的语言，如果采用java语言，自然你会打包成war包，部署在Tomcat或者Jetty这样的应用服务器上，如果你使用spring boot还可以打包成jar包部署。其他还有Rails和Node.js应用以目录层次的形式打包。

         【微服务架构】则是将单个的整体应用程序分割成更小的项目关联的独立的服务。一个服务通常实现一组独立的特性或功能，包含自己的业务逻辑和适配器。各个微服务之间的关联通过暴露api来实现。这些独立的微服务不需要部署在同一个虚拟机，同一个系统和同一个应用服务器中。

六、传统架构—>微服务架构

        单一架构模式在项目初期很小的时候开发方便，测试方便，部署方便，运行良好。可是当应用随着时间的推进，加入的功能越来越多，最终会变得巨大，一个项目中很有可能数百万行的代码，互相之间繁琐的jar包。        

       1、    不再适用敏捷开发，过于复杂，任何开发者都不能够完全理解，修复漏洞和实现新功能变得困难和耗时。

       2、    规模越大，启动时间越长，自然会拖慢开发进度，一个小功能的修改部署起来变得困难，必须重新部署整个应用。

       3、    系统的不同的模块的需要不同的特定的虚拟机环境时，由于是整体应用，那么只能折中选择。

       4、    任意模块的漏洞或者错误都会影响这个应用，降低系统的可靠性

       5、    还有一个如果想整体应用采用新的技术，新的框架或者语言，那是不可能的。

    单体架构在规模比较小的情况下工作情况良好，但是随着系统规模的扩大，它暴露出来的问题也越来越多，主要有以下几点： 
 
    1.复杂性逐渐变高 
 
        比如有的项目有几十万行代码，各个模块之间区别比较模糊，逻辑比较混乱，代码越多复杂性越高，越难解决遇到的问题。 
 
    2.技术债务逐渐上升 
 
        公司的人员流动是再正常不过的事情，有的员工在离职之前，疏于代码质量的自我管束，导致留下来很多坑，由于单体项目代码量庞大的惊人，留下的坑很难被发觉，这就给新来的员工带来很大的烦恼，人员流动越大所留下的坑越多，也就是所谓的技术债务越来越多。 
 
    3.部署速度逐渐变慢 
 
        这个就很好理解了，单体架构模块非常多，代码量非常庞大，导致部署项目所花费的时间越来越多，曾经有的项目启动就要一二十分钟，这是多么恐怖的事情啊，启动几次项目一天的时间就过去了，留给开发者开发的时间就非常少了。 
 
    4.阻碍技术创新 
 
        比如以前的某个项目使用struts2写的，由于各个模块之间有着千丝万缕的联系，代码量大，逻辑不够清楚，如果现在想用spring mvc来重构这个项目将是非常困难的，付出的成本将非常大，所以更多的时候公司不得不硬着头皮继续使用老的struts架构，这就阻碍了技术的创新。 
 
    5.无法按需伸缩 
 
        比如说电影模块是CPU密集型的模块，而订单模块是IO密集型的模块，假如我们要提升订单模块的性能，比如加大内存、增加硬盘，但是由于所有的模块都在一个架构下，因此我们在扩展订单模块的性能时不得不考虑其它模块的因素，因为我们不能因为扩展某个模块的性能而损害其它模块的性能，从而无法按需进行伸缩。 

            如果采用微服务架构模式，则可以解决单一架构模式带来的系统复杂性。主要包括以下几个好处：

            1、    由于每个服务都是独立并且微小的，由单独的团队负责，仍然可以采用敏捷开发模式，自由的选择合适的技术，甚至可以重写老服务，当然都要遵守统一的API约     定。

            2、    每一个微服务都是独立部署的，可以进行快速迭代部署，根据各自服务需求选择合适的虚拟机和使用最匹配的服务资源要求的硬件。

            3、    整体应用程序被分解成可管理的模块和服务，单个的服务可以更快的开发、更简单的理解和维护。

           4、    一些需要进行负载均衡的服务可以部署在多个云虚拟机上，加入NGINX这样的负载均衡器在多个实例之间分发请求，这样不需要整个应用进行负载均衡了。

每个后端服务暴露一套REST API，大部分服务调用其他服务提供的API。每个服务都有自己的数据库模式，而不是共享单个数据库模式。尽管这会造成某些数据的冗余，但是对于微服务架构这个独立数据库模式是必要的，确保了独立服务之间的松散耦合。

         以上介绍的微服务架构模式表面上类似于SOA，两种架构都包含一组服务。可以认为微服务架构是不包括Web服务规范（WS-）、企业服务总线（ESB）的SOA。基于微服务的应用倾向于使用更简单轻量级的协议，比如 REST 而不是 WS-。微服务自己实现类似 ESB 的功能并且拒绝 SOA 的其他部分，比如规范模式的概念。

        微服务的缺点：      

         1、  微服务应用作为分布式系统带来了复杂性。当应用是整体应用程序时，模块之间调用都在应用之内，即使进行分布式部署，依然在应用内调用。可是微服务是多个独立的服务，当进行模块调用的时候，分布式将会麻烦。

         2、  多个独立数据库，事务的实现更具挑战性。

         3、  测试微服务变得复杂，当一个服务依赖另外一个服务时，测试时候需要另外一个服务的支持。

         4、  部署基于微服务的应用也很复杂，整体应用程序部署只需要部署在一组相同的服务器上，在这些服务前面加入传统的负载均衡器即可。独立服务的不是讲变得复杂，需要更高的自动化形式。

          【总结】

1. 单体架构所有的模块全都耦合在一块，代码量大，维护困难，微服务每个模块就相当于一个单独的项目，代码量明显减少，遇到问题也相对来说比较好解决。

2. 单体架构所有的模块都共用一个数据库，存储方式比较单一，微服务每个模块都可以使用不同的存储方式（比如有的用redis，有的用mysql等），数据库也是单个模块对应自己的数据库。

3. 单体架构所有的模块开发所使用的技术一样，微服务每个模块都可以使用不同的开发技术，开发模式更灵活。

         微服务的决定因素：

• 小：微服务体积小，2 pizza 团队。

• 独：能够独立的部署和运行。

• 轻：使用轻量级的通信机制和架构。

• 松：为服务之间是松耦合的。