微服务架构介绍

微服务架构十二要素：

这十二要素可以说是微服务架构的方法论，有了思想，方法论和战术维度，我觉得就可以完整的描绘出一个微服务架构的全景图。然后，我将我理解的微服务架构总结成一句话：微服务架构是 一种去中心化的分布式服务架构，架构拥有服务寻址，故障容错，流量调度，控制访问和可观测性的服务治理能力，从而实现服务的隔离性，可移植性，可扩展性，稳定性。

微服务的难点？

第一个难点， 微服务的服务治理和流量治理。

对于这个难点，现阶段已经有了很好的解决，因为服务治理和流量治理是去业务场景化的，所以有很多前人通过他们的努力，以及贡献的开源框架，让我们可以直接可以拿来落地的，并且可以做到很好的兼容。下图是一个比较标准的微服务治理架构图：

第二个难点， 微服务拆分的架构思想.

如何基于DDD方法论落地服务的分解。该处设计很多核心能力，包括子域划分，限界上下文定义，实体，聚合根的抽象，基于领域事件的事件驱动设计，除此之外，还有工厂模式，策略等等设计模式的应用。

微服务架构的好处：

1 使大型的复杂应用程序可以持续交付和持续部署：自动化测试编写起来更简单，devops搞起来更方便。

2 每个服务相对较小并容易维护：服务更小，代码库规模更小，开发人员读起来更易懂，打包部署和测试更方便，程序启动更快。

3 服务可以独立部署、独立扩展：可以采用X轴扩展的实例克隆，Z轴扩展进行流量分区。此外，每个服务都可以部署在适合他们需求的硬件之上，这与单体架构的部署和硬件选型是截然不同的，单体应用中组件对硬件的需求不同，但是这些组件仍旧必须被部署在一起。（有些组件是CPU运算密集型的，有些则可能需要更多的存储空间）

4 微服务架构可以实现团队的自治。

5 更容易实现和采纳新的技术：开发一个新的服务时，开发者可以自由选择适用于这个服务的任何语言与框架。

6 更好的容错性：某个服务的内存泄漏不会影响其它服务，其它服务仍旧可以正常地响应请求。

微服务架构的挑战：

服务的拆分和定义是一项挑战

 服务间通信方式：

可以基于同步请求/响应的通信机制，例如http rest和grpc, 也可以使用异步的基于消息的通信机制，比如AMQP或者STOMP。消息的格式也不尽相同，可以使用具备可读性的格式，比如基于文本的JSON或XML。也可以使用更加高效的、基于二进制的Avro或Protocol Buffers格式。

交互方式：

	一对一	一对多
同步模式	请求/响应	无
异步模式	异步请求/响应 单向通知	发布/订阅 发布/异步响应

开发可靠的远程过程调用代理：

网络超时：在等待针对请求的响应时，一定不要做成无限阻塞，而是要设定一个超时。使用超时可以保证不会一直在无响应的请求上浪费资源。

限制客户端向服务器发出请求的数量：把客户端能够向特定服务发起的请求设置一个上限，如果请求达到了这样的上限，很有可能发起更多的请求也无济于事，这时就应该让请求立即失败。

断路器模式：监控客户端发出请求的成功与失败数量，如果失败的比例超过一定的阙值，就启动断路器，让后续的调用立刻失效。如果大量的请求都以失败告终，这说明被调服务不可用，这样即时发起更多的调用也是无济于事。在经过一定的时间后，客户端就应该继续尝试，如果调用成功，则解除断路器（Hystrix）。

服务发现与注册：

现代的服务实例具有动态分配的网络位置。此外，由于自动扩展、故障和升级，服务实例集会动态更改。因此客户端代码必须使用服务发现。实现服务发现主要有两种方式：

1 应用层服务发现方式：应用程序的服务及其客户端与服务注册表进行交互。服务实例使用注册表注册其网络位置，客户端通过查询服务注册表获得服务实例列表来调用服务，然后向其中一个实例发送请求。这种服务发现方法是两种模式的组合。