软件架构模型-微服务架构
总览
- 分层体系结构（Layered architecture）
- 事件驱动架构（Event-driven architecture）
- 微内核架构（Microkernel architecture）
- 微服务架构（Microservices architecture）
- 基于空间的架构（Space-based architecture）
（尽信书不如无书，此处可能不全，仍有其他架构）
微服务架构
下面主要讲述几个关键概念来理解微服务架构的益处及何种场景下选择此种模型。
独立部署单元
如下图，每一个 组件 作为一个独立的单元部署，随之而来的，可以方便得进行迭代开发、增加扩展、及高度得与其他组件解耦。
其最重要的一个概念是 服务组件 ，服务组件包含了一个或多个子模块，分别负责独立部分的服务。由此在微服务中，按合适的粒度来分组件就是至关重要的一个问题
Basic Microservices architecture pattern.png
分布式体系
另一个重要的概念是分布式架构，即在架构上所有组件是完全解耦的，它们的通信要靠 远程访问协议（remote access protocol）如（JMS, AMQP, REST, SOAP, RMI等等）来实现通信。
微服务架构的一个令人兴奋的事情之一是，它是从其他常见架构模式中演变而来的，而不是被创建为等待问题发生的解决方案。它的演变来源主要有两个：使用分层架构模式的单体应用程序；通过面向服务的架构模式（SOA）的分布式应用程序。
单体应用的整体通常紧密耦合成一个单元，使其测试和部署十分麻烦，而且常常因为脆弱的应用程序导致部署中断。微服务可通过部署多个小单元（服务组件）来解决这些问题，独立开发、测试和部署。
另一个来源是面向服务的架构模式（SOA）。尽管 SOA 非常强大，并提供了无与伦比的抽象水平，异构连接，服务编排及使业务目标与 IT 功能保持一致的希望，但它非常复杂、昂贵、难以实施，并且通常过大适用于大多数应用。微服务架构风格通过简化服务概念，消除编排需求以及简化服务连接和服务访问来解决其复杂性。
通信模式（拓扑模式）
实现微服务架构模式的方式有很多种，但主要有三种非常流行，分别是：
- 基于 REST-API 的拓扑
- 基于 REST 应用的拓扑
- 基于消息中心（Centralized Messaging）的拓扑
基于 REST API 的拓扑
如上图，基于 REST-API 的拓扑一般是由非常细粒度的独立的服务组件（因此叫微服务）组成。
基于 REST 应用的拓扑与基于 REST-API 的拓扑不同之处在于，服务组件是一个传统应用或一个稍大的应用体，而不是一个仅仅的 API 层。该应用程序是一个独立的 Web 应用，对于具有相对较低复杂度的中小型企业应用程序，此拓扑是非常常见的。
集中式消息传递拓扑 通常在大型业务应用或一些应用之间有复杂控制的应用程序中找到。它的好处在于有 排队机制、异常通信、监视、错误处理，以及更好的负载均衡和可扩展性。单点故障和瓶颈问题通常通过代理集群和代理联合（将单个代理实例拆分成多个实例，以根据系统功能来分割吞吐量）来解决。
sapr_0404.png
使用建议
避免依赖和编排
微服务架构模式的主要挑战之一是为服务组件确定 正确的粒度级别。如果粒度过大，你可能不会意识到此体系结构的好处（部署、可伸缩、可测试、低耦合）。
而过于细小的粒度会导致有 编排需求，这将将你的微服务架构转变成重量级的面向服务的架构（SOA），并具有 SOA 通常遇到的所有复杂、混乱、开销大、易出错等问题。
如果你发现你需要编排你的服务组件，则可能是服务组件粒度太细了。同样，如果发现需要在服务组件中执行服务间通信以处理单个请求，那从业务角度来看，粒度也是太细了。
可以通过共享数据库来处理服务间通信，比如订单服务来调客户信息，可以通过直接调数据库而不是客户模块来完成。但这种方式可能导致服务间的意外耦合。
如果你发现无论服务组件粒度如何划分，都无法避免服务编排，那么这很好地表明了这可能不是你的应用正确的架构模式。由于这种模式具有分布式特性，因此很难在 服务组件间 维护 事务性 的工作，用事务补偿框架的回滚反而极大得增加了其复杂性。
注意事项
微服务架构模式解决了单体应用和面向服务架构中的许多常见问题。
其特点是应用程序组件被分解为较小的，单独部署的单元，因此微服务构建的应用通常 更健壮，提供更好的 可伸缩性且支持 持续交付。
最后一个考虑因素是，由于其是分布式架构，因此存在一些分布式架构中共有的复杂问题，比如契约创建、维护和管理，远程系统可用性和访问授权等等。
优劣分析
- 整体灵活
- 易开发
- 易部署
- 易测试
- 可扩展性高
- 性能低（分布式的性质）
