微服务

Web Service 与企业级分布式服务

服务提供者通过 WSDL（Web服务描述语言，Web Services Description Language）向注册中心（Service Broker）描述自身提供的服务接口属性，注册中心使用 UDDI（Universal Description, Discovery, and Integration，统一描述、发现和集成）发布服务提供者提供的服务，服务请求者从注册中心检索到服务信息后，通过 SOAP（Simple Object Access Protocol，简单对象访问协议 ）和服务提供者通信，使用相关服务。



Web Service 虽然有着成熟的技术规范和产品实现，以及在企业应用领域有许多成功的案例，但是也具有一些固有的缺点：

• 臃肿的注册与发现机制

• 低效的 XML 序列化手段

• 开销相对较高的 HTTP 远程通信

• 复杂的部署与维护手段



微服务框架需求

对于大型互联网系统，除了 Web Service 所规范的服务注册与发现，服务调用等标准功能，还需要微服务框架能够支持：

失效转移（Fail Over）--高可用

负载均衡

高效的远程通信

对应用最少侵入

版本管理



Service Mesh 服务网格

Service Mesh 是一个基础设施层，用于处理服务间的通信，通常表现为一组轻量级网络代理，他们与应用程序部署在一起，而对应用程序透明。

Service Mesh 的 Sidecar 模式

Sidecar之间连接形成网络

微服务架构实践

微服务架构落地

• 业务先行，先理顺业务边界和依赖，技术是手段而不是目的。

• 先有独立的模块，后有分布式的服务。

• 业务耦合严重，逻辑复杂多变的系统进行微服务重构要谨慎。

• 要搞清楚实施微服务的目的是什么，业务复用？开发边界清晰？分布式集群提升性能？

命令与查询职责隔离（CQRS）

在服务接口层面将查询（读操作）与命令（写操作）隔离，实现服务层的读写分离。

• 更清晰的领域模型

• 针对读写分别优化，实现更好的性能

• 查询服务不会修改数据，更好地保护数据

事件溯源

将用户请求处理过程中的每次状态变化都记录到事件日志中，并按时间序列进行持久化存储。

• 利用事件溯源，可以精确复现任何用户状态，进行复核审计。

• 利用事件溯源，可以有效监控用户状态变化，并在此基础上实现分布式事务。

断路器

当某个服务出现故障，响应延迟或者失败率增加，继续调用这个服务会导致调用者请求阻塞，资源消耗增加，进而出现服务级联失效，这种情况下使用断路器阻断对故障服务的调用。

服务重试及调用超时

上游调用者超时时间要大于下游调用者超时时间之和。



最重要的是需求

需求驱动，而不是框架驱动。



微服务网关

基于网关的微服务架构



网关作用

统一接入

安全防护

协议适配

流量控制与容错



微服务网关



网关管道技术

实现管道技术的责任链设计模式

Flower 异步网关与异步微服务框架

利用 Servlet3 实现异步网关



开放平台网关

• API 接口:是开放平台暴露给合作者使用的一组 API，其形式可以是 RESTful、 WebService、RPC 等各种形式

• 协议转换:将各种 API 输入转换成内部服务可以识别的形式，并将内部服务的返回 封装成 API 的格式。

• 安全:除了一般应用需要的身份识别、权限控制等安全手段，开放平台还需要分级 的访问带宽限制，保证平台资源被第三方应用公平合理使用，也保护网站内部服务不会 被外部应用拖垮。

• 审计:记录第三方应用的访问情况，并进行监控、计费等。

• 路由:将开放平台的各种访问路由映射到具体的内部服务。

• 流程:将一组离散的服务组织成一个上下文相关的新服务，隐藏服务细节，提供统 一接口供开发者调用。



开放授权协议 OAuth2.0

授权码授权

OAuth2.0 一共有四种授权方式，分别是授权码、隐式授权、资源所有者密码 凭据和客户端凭据。

目前互联网上使用最多也是最安全的的一种方式是授权码方式。



领域驱动设计 DDD

领域模型

事务脚本

领域模型

贫血模型 VS 充血模型

DDD 战略设计

领域驱动设计就是从领域出发，分析领域内模型及其关系，进而设计软件系统的方法。



子域

领域是一个组织所做的事情以及其包含的一切。 这个范围就太大了，不知道该如何下手。所以通常的做法是把整个领域拆分成多个子域，比如用户、商品、订单、库存、物流、发票等。



限界上下文

在一个子域中，会创建一个概念上的领域边界，在这个边界中，任何领域对象都只表示特定于该边界内部的确切含义。这样边界便称为限界上下文。限界上下文和子域具有一对一的关系，用来控制子域的边界，保证子域内的概念统一性。

通常限界上下文对应一个组件或者一个模块，或者一个微服务，一个子系统。

上下文映射图

不同的限界上下文，也就是不同的子系统或者模块之间会有各种的交互合作。DDD 使用上下文映射图来设计这种关联和交互。



DDD 战术设计

实体

领域模型对象也被称为实体，每个实体都是唯一的，具有一个唯一标识，一个订单对象是一个实体，一个产品对象也是一个实体，订单 ID 或者产品 ID 是它们的唯一标识。实体可能会发生变化，比如订单的状态会变化，但是它们的唯一标识不会变化。

值对象

并不是领域内的对象都应该被设计为实体，DDD 推荐尽可能将对象设计为值对象。比如像住址这样的对象就是典型的值对象，也许建在住址上的房子可以被当做一个实体，但是住址仅仅是对房子的一个描述，像这样仅仅用来做度量或描述的对象应该被设计为值对象。

聚合

聚合是一个关联对象的集合，我们将其作为一个单元来处理数据更改。每个集合都有一个根和一个边界。边界定义了聚合内部的内容。根是聚合中包含的单个特定实体。

聚合根：将多个实体和值对象聚合在一起的实体。

DDD 分层架构

领域实体的组合调用和事务控制在应用层。



组件设计原则



组件内聚原则

组件内聚原则主要讨论哪些类应该聚合在同一个组件中，以便组件既能提供相对完整的功能，又不至于太过庞大。

复用发布等同原则

复用发布等同原则是说，软件复用的最小粒度应该等同于其发布的最小粒度。

共同封闭原则

共同封闭原则是说，我们应该将那些会同时修改，并且为了相同目的而修改的类放到同一个组件中。而将不会同时修改，并且不会为了相同目的而修改的类放到不同的组件中。

共同复用原则

共同复用原则是说，不要强迫一个组件的用户依赖他们不需要的东西。



组件耦合原则

组件内聚原则讨论的是组件应该包含哪些功能和类，而组件耦合原则讨论组件之间的耦

合关系应该如何设计。

无循环依赖原则

无循环依赖原则说，组件依赖关系中不应该出现环。

稳定依赖原则

稳定依赖原则说，组件依赖关系必须指向更稳定的方向。较少变更的组件是稳定的，也就是说，经常变更的组件是不稳定的。根据稳定依赖原则，不稳定的组件应该依赖稳定的组件，而不是反过来。

稳定抽象原则

稳定抽象原则说，一个组件的抽象化程度应该与其稳定性程度一致。也就是说，一个稳定的组件应该是抽象的，而不稳定的组件应该是具体的。



组件的边界与依赖关系，不仅仅是技术问题