一、分布式微服务架构设计原理

一、 从传统单体架构到服务化架构

JEE架构

JEE将企业级软件架构分为三个层级：web层、业务逻辑层和数据存取层，每个层次的职责分别如下
    Web层：负责与用户交互或者对外提供接口
    业务逻辑层：为了实现业务逻辑而设计的流程处理和计算处理模块
    数据存取层：将业务逻辑层处理的结果持久化以待后续查询，并维护领域模型中对象的生命周期。

SSH架构：struts+spring+hibernate

服务化架构(SOA)

1. web service：soap协议（在HTTP/HTTPS通道上传输XML数据）

2. ESB：企业服务总线的简称，用于设计和实现网络化服务交互和通信的软件模型

• ESB的核心在于企业服务总线的功能和职责:
      监控和控制服务之间的消息路由
      控制可插拔的服务化的功能和版本
      解析服务之间交互和通信的内容和格式
      通过组合服务、资源和消息处理器来统一编排业务需要的信息处理流程
      使用冗余来提供服务的备份能力

二、 从服务化到微服务

微服务架构的产生

• 微服务架构倡导将软件应用设计成多个可独立开发、可配置、可运行和可维护的子服务，子服务之间通过良好的接口定义通信机制，通常使用RESTful风格的API形式来通信，因为RESTful风格的API通常是在HTTP或者HTTPS通道上传输JSON格式的数据来实现的，HTTP协议有跨语言、跨异构系统的有点，当然，也可以通过底层的二进制协议、消息队列协议等进行交互。这些服务不需要中心化的统一管理，每个服务的功能可自治，并且可以由不同的语言，系统和平台实现。

• 微服务架构致力于松耦合和高内聚的效果，与SOA和ESB相比，不在强调服务总线和通信机制的多样性，常常通过RESTful风格的API和轻量级的消息通信协议来完成。

• 微服务架构可以追溯到UNIX操作系统的管道命令

• 微服务架构并不是为了拆分而拆分，真正的目的是通过对微服务进行水平扩展解决传统的单体应用在业务急剧增长时遇到的问题。而且拆分的为服务系统中专业的人做专业的时，人员和项目的职责单一、低耦合、高内聚，所以产生问题的概率就会降到最小。

微服务架构与传统单体架构的对比

微服务架构:

-微服务把每一个职责单一的功能放在一个独立的服务中

• 每个服务运行在一个单独的进程中
• 每个服务有多个实例在运行，每个实例可以运行在容器化平台内，达到平滑收缩的效果
• 每个服务有自己的数据存储，实际上，每个服务应该有自己独享的数据库、缓存、消息队列等资源
• 每个服务应该有自己的运营平台，以及独享的运营人员，这包括技术运维和业务运营人员；每个服务都高度自治，内部的变化对外透明。
• 每个服务都可根据性能需求独立地进行水平伸缩

传统单体架构：

• 传统单体架构将所有模块化组件混合后运行在同一个服务JVM进程中；可对包含多个模块化组件的整体JVM进程进行水平扩展，而无法对某个模块化组件进行水平扩展，某个模块化组件发生变化时，需要所有的模块化组件进行编译、打包和上线，久而久之，模块间的依赖将会不清晰，互相耦合、互相依赖成为家常便饭

微服务架构与SOA服务化的对比

目的不同

• SOA服务化涉及的范围更广一些，强调不同的异构服务之间的协作和契约，并强调有效集成、业务流程编排、历史应用集成等，典型代表为WebService和ESB
• 微服务使用一系列的微小服务来实现整体的业务流程，目的是有效地拆分应用，实现敏捷开发和部署，在每个微小服务的团队里，减少了跨团队的沟通，让专业的人做专业的事，缩小变更和迭代影响的范围，并达到单一的微服务更容易水平扩展的目的。

部署方式不同

SOA服务化同城将多个业务服务通过组件化模块方式打包在一个War包里，然后统一部署在一个应用服务器上
微服务将完整的应用拆分成多个细小的服务，通常使用敏捷扩容、缩容的Docker技术来实现自动化的容器管理，每个微服务运行在单一的进程内，微服务中的部署互相独立，互不影响。

服务粒度不同

• SOA对粒度没有要求，在实践中服务通常是粗粒度的，强调接口契约的规范化，内部实现可以更粗粒度
• 微服务倡导将服务拆分成更细的粒度，通过多个服务组合来实现业务流程的处理，拆分到职责单一，甚至小到不能再进行拆分。

三、微服务架构的核心要点和实现原理

微服务架构中职能团队的划分

• 微服务架构按照业务的功能进行划分，每个单一的业务功能叫做一个服务，每个服务对应一个独立的职能团队，团队里包含用户交互UI设计师，后台服务开发人员、DBA、运营和运维人员。
• 在微服务架构中，提倡运维人员也是服务项目团队的一员，倡导谁开发、谁维护，实施终生维护制度。
• 在业务服务的内部实现需要升级或者变更时，团队内的各角色成员进行沟通即可，而不需要进行跨团队沟通，这大大提高了沟通效率，只有服务之间的接口需要变更时才需要跨部门沟通，可以通过一定的设计模式和规范来解决。

微服务的去中心化治理

微服务倡导去中心的治理，不推荐每个微服务都是用相同的标准和技术来开发和使用服务。在微服务架构下可以使用C++开发一个服务，来对接Java开发的另外一个服务，对于异构系统之间的交互标准，通常可以使用工具来补偿。开发者可以开发共用的工具，并分享給异构系统的开发者使用，来解决异构系统不一致的问题。
微服务架构倡导去中心化的服务管理和治理，尽量不设置中心化的管理服务，最差也需要在中心化的管理服务宕机时有替代方案和设计。

微服务的交互模式

读者容错模式：指微服务化中服务提供者和消费者之间如何对接口的改变进行容错
消费者驱动契约模式：用来定义服务化中服务之间交互接口改变的最佳规则。
服务契约分为：提供者契约、消费者契约及消费者驱动的契约
去数据共享模式：
在设计微服务架构时，一定不要共享缓存和数据库等资源，也不要使用总线模式，服务之间的通信和交互只能依赖定义良好的接口，通常使用RESTful样式的API或者透明的RPC调用框架

微服务的分解和组合模式

• 服务代理模式
• 服务聚合模式
• 服务串联模式
• 服务分支模式
• 服务异步消息模式
• 服务共享数据模式：应用场景：单元化架构、遗留的整体服务

微服务的容错模式

• 舱壁隔离模式
  微服务容器分组、线程池隔离
• 熔断模式
• 限流模式：计数器、令牌筒、信号量
• 失效转移模式

微服务的粒度

根据业务需要，能够满足上层服务对底层服务自由编排并获得更多的业务功能即可，并需要适合团队的建设和布局。

四、Java平台微服务架构的项目组织形式

微服务项目的依赖关系

一方库：本服务在jvm进程内依赖的jar包
二方库：在服务外通过网络通信或者RPC调用的服务的jar包
三方库：所依赖的其他公司或者组织提供的服务或者模块

微服务项目的层级关系

服务导出层
接口层
逻辑实现层

微服务项目的持续发布

代码管理、自动编译、发布QA、自动化测试、性能测试、准生产部署和测试、生产环境发布等。

五、服务化管理和治理框架的技术选型

• RPC：JDK RMI、Hessian及Burlap
• 服务化：Dubbo、HSF、Thrift、AXIS、Mule ESB
• 微服务：spring boot、Netflix、spring cloud Netflix