---

文章目录

什么是微服务与单体系统的区别(微服务相对单体系统的优点)服务拆分引发的问题(缺点)如何实施微服务服务组件化智能端点和哑管道去中心化治理去中心化管理数据基础设计自动化容错设计

---

什么是微服务

简单来说，微服务是系统架构上的一种设计风格，它的主旨是将一个原本独立的系统拆分成多个小型服务(由单进程演化为多进程)，这些服务之间通过基于HTTP的RESTful API进行通信协作。被拆分的每一个小型微服务都各自围绕自身的业务进行构建，数据存储，开发和维护。

与单体系统的区别(微服务相对单体系统的优点)

修改小功能后不需要全部服务重新部署在资源利用方面，各个服务之间互相影响减小解决了单体系统变得庞大臃肿之后产生的难以维护的问题，减低维护成本更准确地为每个服务评估性能容量

服务拆分引发的问题(缺点)

运维的新挑战，运维需要维护的进程数量增加。接口的一致性，虽然服务被拆分，但是业务逻辑上的依赖并不会消除，只是从单体应用中的代码依赖变为了服务间的通信依赖。当我们对原有接口进行修改，交互方也需要协调这样的改变来进行发布，以保证接口的正确调用。需要更完善的接口和版本管理，或是严格遵循开闭原则。分布式的复杂性，由于拆分后的微服务都是独立部署并运行在各自的进程内，只能通过通信来协作，所以分布式的环境问题都是微服务架构设计时需要考虑的因素，比如网络延迟，分布式事务，异步消息等

如何实施微服务

服务组件化

在微服务中，需要我们对服务进行组件化分解。然后通过HTTP等通信协议进行协作。每一个服务都独立开发，部署，可以有效避免一个服务的修改引起整个系统的重新部署。

智能端点和哑管道

在单体应用中，组件间直接通过函数调用的方式进行交互协作。而在微服务架构中，由于服务不在一个进程中，组件间的通信模式发生了改变，若仅仅将原本在进程内的方法调用改成RPC方式的调用，会导致微服务之间产生繁琐的通信，使得系统表现糟糕，所以我们需要更粗粒度的通信协议

一般采用以下两种：

使用HTTP的RESTful API或轻量级的消息发送协议，实现信息传递与服务调用的触发。通过在轻量级消息总线上传递消息，类似RabbitMQ等一些提供可靠异步交换的中间件。

去中心化治理

在实施微服务架构时，通过采用轻量级的契约定义接口，使得我们对服务本身的具体技术平台不再那么敏感，这样整个微服务架构系统中的各个组件就能争对其不同的业务特点选择不同的技术平台。终于不会出现杀鸡用牛刀或是杀牛用指甲钳的尴尬处境了。

去中心化管理数据

数据管理去中心化:让每一个服务来管理其自有的数据库。

不过，由于数据存储于不同的数据库实例中后，数据一致性也成为微服务架构中亟待解决的问题之一。所以在微服务架构中，我们更强调在各服务之间进行"无事务"的调用，而对数据一致性，只要求数据在最后的处理状态是一致的即可:若在过程中发现错误，通过补偿机制来进行处理，使得错误数据能够达到最终的一致性。

基础设计自动化

自动化测试:每次部署前的强心剂，尽可能地获得对正在运行的软件的信心。自动化部署:解放烦琐枯燥的重复操作以及对多环境的配置管理。

容错设计

单体应用中，一般不存在单个组件故障而其他部件还在运行的情况，通常是一挂全挂。而在微服务架构中，则会出现部分服务出现故障，而其他服务正常运行的情况。所以，在服务架构中，快速检测出故障源并尽可能地自动恢复是必须被设计和考虑的。通常，我们都希望在每个服务中实现监控和日志记录的组件，比如服务状态，断路器状态，吞吐量，网络延迟等关键数据的仪表盘等。