这是我参与「第五届青训营」伴学笔记创作活动的第 1 天

微服务架构的简单介绍

简介

微服务最早由Martin Fowler与James Lewis于2014年共同提出，微服务的精髓在于一个微字，所谓微就是每个服务的体量都很小，功能不复杂。微服务风格是一种使用一套小服务来开发单个应用的方式途径，每个服务运行在自己的进程中，并使用轻量级机制通信，比如说http协议或者rpc协议等等。微服务的每一个服务都可以单独运行，因此服务具有很强的独立性，不会影响到其他的服务

优点

以前大家都是使用的单体架构，单体架构有优点也有缺点优点是他每个功能和功能之间的响应很迅速因为不需要经过任何的网络都是内部调用，缺点也很明显，把所有功能都写在一起，不仅仅让开发人员难以维护，无法快速的找到问题所在更是让容灾的成本大大升高，当服务的某个功能出问题就需要将整个服务进行降级或者其他容灾，这样不仅让容灾时间变长更是会让容灾的成本升高。而微服务就能够比较好的解决这个问题，微服务的每个服务都是单独部署的，当某个服务出问题映射的就是用户的某个需求出问题，所以根据服务功能就可以很快的找出问题所在，而且不同功能的服务之间有些是不相关的这样就让其他不相干的功能依然可以使用。容灾成本也相应下降，我们只需要对出问题的服务进行容灾。

缺点

微服务的缺点也很明显，比如怎么样的一个服务才算一个微服务，服务要怎么去合理的拆分，目前没有很好的解决办法，只能根据具体的情况需求再进行判断。再一个就是，服务小但是数量多庞大数量的微服务要怎么去管理？目前的方案是写一套服务治理。

服务治理

接下来讲一讲微服务的服务治理，主要的有服务发现，链路追踪，以及服务监控和服务熔断，服务容灾等等。服务发现是服务治理必须要有的他能够通过找寻我们注册过的服务将用户的请求均衡的分配到指定服务上，当然这里会有负载均衡策略。链路追踪和服务监控则是对请求的走向以及服务的性能进行监控保证开发人员对项目的正确性的了解。服务熔断和容灾都是当出现问题时需要做的。