现在越来越多的项目架构正在趋向于微服务架构，原来一个系统可能很庞大，很多功能都集中在同一个项目当中。特别是项目更新迭代或者增加新的需求的时候，对于服务器的更细有时会是一件很麻烦的事情。作为一个Web开发人员，认识和学习微服务是一件很有必要的事情。本文从几个方面逐步介绍微服务，由于本人也是刚刚接触微服务不太久，写文总结也是一个学习的过程。

什么是微服务？

       微服务是一种架构思想，即把一个大型的单个应用程序拆分成多个不同模块的服务(小的应用)。微服务的架构思想是让应用程序的开发和维护越来越简单化，使项目更便于维护。传统的项目风格中，可能有十几甚至二十个功能，如果只需要对该系统中的某一个功能进行更新，在更新服务的时候需要对整个服务进行更新。而如果采用微服务的架构，每个功能都是一个独立的服务，各项服务之间独立运行，整个项目整合了各个服务。如果我们需要对某一项功能进行更新，只需要更新该项功能对应的服务，而不用去操作其他功能功能的服务。

      微服务就是一些小而自治的服务，一个庞大的项目可以有多个微服务组成，每个微服务可以有自己的数据库，可以使用自己的开发语言等等。微服务可以根据不同的业务逻辑来进行拆分，将处理的业务逻辑相似的功能放在一个服务中。每个微服务都具有自治性，它是一个独立的实体，它可以独立部署，独立修改，服务于服务之间通过API进行通信。这样就避免了服务于服务之间的技术相关性，及不同的服务之间可以使用不同的技术(开发语言、项目架构等)来进行实现。

为什么需要微服务

       我们在设计应用的时候，从代码层面考虑要求在开发的过程当中松耦合，一个逻辑的修改不影响其他逻辑。那么系统的结构设计的时候，同样是一种松耦合的思想，一个模块的修改不影响另一个模块的运行。而传统的系统结构，把所有的业务都放在同一个系统中，虽然在更新系统的时候只更新了某一个模块，但是在部署项目时实际上是重新部署了所有模块。

我们可以通过一张图来只管的比较一下传统的单体应用和微服务之间的区别

单体应用与微服务

     传统的单体应用，随着业务的增多，代码的维护以及应用的升级会越来越麻烦，特别是比较多啊的系统，只是更新一个小小的模块，就需要整个应用全部更新。特别是现在，企业一方面要求应用能够快速上线，另一方面对应用的更新也比较频繁。这就需要将应用根据功能进行划分，当更新一部分的功能时不会影响其他功能的正常运行。

微服务的优缺点

任何一个思想的出现，都是为了更好地解决当下遇到的问题，但是"金无足赤人无完人"，微服务思想相对于当前的单体应用来说有很大的优点，但是也避免不了有些缺点。

微服务的优点：

 每个服务都比较简单，只关注于一个业务功能。

微服务架构方式是松耦合的，可以提供更高的灵活性。

微服务可通过最佳及最合适的不同的编程语言与工具进行开发，能够做到有的放矢地解决针对性问题。

每个微服务可由不同团队独立开发，互不影响，加快推出市场的速度。

微服务架构是持续交付(CD)的巨大推动力，允许在频繁发布不同服务的同时保持系统其他部分的可用性和稳定性。

微服务的缺点：

微服务的一些想法在实践上是好的，但当整体实现时也会呈现出其复杂性。

运维开销及成本增加：整体应用可能只需部署至一小片应用服务区集群，而微服务架构可能变成需要构建/测试/部署/运行数十个独立的服务，并可能需要支持多种语言和环境。这导致一个整体式系统如果由10个微服务组成，可能需要20~30个进程。

代码重复：某些底层功能需要被多个服务所用，为了避免将“同步耦合引入到系统中”，有时需要向不同服务添加一些代码，这就会导致代码重复。

分布式系统的复杂性：作为一种分布式系统，微服务引入了复杂性和其他若干问题，例如网络延迟、容错性、消息序列化、不可靠的网络、异步机制、版本化、差异化的工作负载等，开发人员需要考虑以上的分布式系统问题。

异步机制：微服务往往使用异步编程、消息与并行机制，如果应用存在跨微服务的事务性处理，其实现机制会变得复杂化。

可测性的挑战：在动态环境下服务间的交互会产生非常微妙的行为，难以可视化及全面测试。经典微服务往往不太重视测试，更多的是通过监控发现生产环境的异常，进而快速回滚或采取其他必要的行动。但对于特别在意风险规避监管或投产环境错误会产生显著影响的场景下需要特别注意。

从单体切换到微服务架构我的体会

   从最开始的单体应用到现在切换到微服务架构，在开发的过程当中有很多感触。

单体模式：

    在开发过程当中，都在同一个代码库中做开发，特别是对一些公用的资源(比如配置文件)，做修改之后，有可能对使用同一个参数的相似模块造成一定的影响。之前使用Ngnix做反向代理和负载均衡，不同的服务器启动N个实例，但是每个实例都是相同的项目，每当需要更新一个功能时，需要对每个服务器上的N个实例同步更新。这样的更新存在一个问题:项目的所有模块都在同一个应用中，更新一个小的模块需要对整个应用进行更新。如果在测试环境下，你修改了一个模块，同事修改了一个模块，在升级测试应用时，如果没有将测试的代码完全提交，很容易导致你更新到服务器之后将别人更新的功能给覆盖掉。不过生产环境更新比较方便的一点就是更新的所有服务器都是同一套代码，反向代理和负载均衡配置起来比较简单，只需要指向不同服务器上的不同实例即可。

微服务架构：

    采用微服务架构之后，将不同的模块进行拆分。比方说将整体的项目拆分成了A、B、C、D四个服务。对每个服务的业务比较熟悉的同事可以独立开发这个服务，每个人负责一套代码的管理，这样造成代码冲突的可能性很小。在更新服务时，对其他人的服务也没有任何影响。但是在项目部署的过程当中就会比较麻烦，原来单体服务，在配置负载均衡时，只需要将地址指向不同的实例；而微服务架构，每个服务是一个实例，如果每一个服务需要部署在不同的服务器上，而且还需要在每台服务器上有多个实例。这是配置反向代理的时候就会比较麻烦，需要考虑到每个服务的每台服务器的不同实例。

作者：割草的小猪头
链接：https://www.jianshu.com/p/446242be13b0