微服务：服务本身的设计、维护以及治理



微服务重点在于服务的模块拆解、设计、维护、治理。而不是框架的使用、框架的远程调用、RPC远程调用（入门的内容）。

服务本身要做好（划分、设计），再选择一个技术工具（框架、技术）。



微服务是用来解决巨无霸应用系统带来的问题：

• 编译、部署困难

• 代码分支管理困难

• 数据库连接耗尽

• 新增业务困难



解决的方案就是拆分、将模块独立部署，降低系统耦合性

纵向拆分：将一个大应用拆分为多个小应用，如果新增业务较为独立，那么就直接将其设计部署为一个独立的 Web 应用系统。

横向拆分：将复用的业务拆分出来，独立部署为微服务，新增业务只需要调用这些微服务即可快速搭建一个应用系统。



微服务框架

SOA web service 是最老、最原始的微服务框架。包含了服务提供者、服务请求者、注册中心3个角色。

缺点：

• 臃肿的注册和发现机制

• 低效的 XML 序列化手段

• 开销较高的 HTTP 远程通信

• 复杂的部署与维护手段

难以满足大型网站对系统高性能、高可用、易部署、易维护的要求。



微服务框架除了注册和发现机制、服务调用标准功能、还需要下面功能：

• 负载均衡：对于集群部署的服务提供者，服务请求者可以使用加权轮询等手段访问，使服务提供者集群实现负载均衡

• 失效转移：微服务框架需要支持服务提供者的失效转移机制，以实现服务高可用

• 高效的远程通信：基于长连接、私有定制的协议、二进制的序列化方式、减少数据传输，提高通信速度

• 对应用最少侵入：微服务也需要渐进式的演化。微服务模块本身需要支持集中式部署、也可以分布式部署

• 版本管理：服务升级、接口变更不受影响。服务的版本。



微服务框架 Dubbo 架构

• 服务消费者

• 服务提供者

• 服务注册中心



微服务 落地实践的策略与思路



Service Mesh 服务网格

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



Service Mesh 的 Sidecar 模式



微服务架构实践

微服务架构落地

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

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

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

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



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

• 更清晰的领域模型

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

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



事件溯源

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

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

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



断路器

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



服务重试及调用超时

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



最重要的是需求

• 需求

• 价值

• 原则

• 最佳实践

• 选择对应工具

微服务网关的技术架构

微服务网关的作业

• 统一接入：高性能、高并发、高可用、负载均衡

• 安全防护：防刷控制、黑白名单

• 协议适配：http、dubbo

• 流量管控与容错



微服务网关是微服务中的消费者。



网关管道技术

网关本身没有什么业务，主要职责是各种校验与拦截，这些职责可以通过管道技术连接起来

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



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

• 利用 Servlet3 实现异步网关

开放平台网关

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

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

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

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

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

• 流程：聚合内部服务。



目前互联网上使用最多也是最安全的是：开放授权协议 OAuth2.0 的授权码。

例如网易云音乐使用微信账号登录。

1. Client 是网易云音乐的APP。

2. 用户点击使用微信登录，APP 调起登录的授权界面 User-Agent，用户（也就是 Resource Owner ）点击同意授权，User-Agent 将用户授权信息提交给授权服务器（Authorization Server 微信的授权服务器），授权服务器返回用户同意的授权码（Authorization Code），授权页面再将授权码返回给网易云音乐。

3. 网易云音乐用授权码到 Authorization Server 进行登录验证，拿到用户的 Access Token。

领域驱动设计 DDD

领域模型是合并了行为和数据的领域的对象模型。通过领域模型对象的交互完成业务逻辑的实现，也就是说，设计好了领域对象，也就设计好了业务逻辑实现。和事务脚本的贫血模型相对应，领域模型被称为充血模型。



领域是一个组织所做的事情以及包含的一切，通俗地说，就是组织的业务范围和做事方式，也是软件开发的目标范围。

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



子域：通常再把领域拆分为多个子域。如用户、商品、订单、物流等。

限界上下文 = 子域



实体

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

实体设计是 DDD 核心所在，首先通过业务分析，识别出实体对象，然后通过相关的业务逻辑设计实体的属性和方法。这里最重要的是要把握住实体的特征是什么，实体应该承担什么职责。



值对象

一个特点是创建之后不能再改变了。比如地址，如果改变了，就是一个新地址了；而一个订单的实体则可能发生改变。

通过传递值对象，解决方法中 getById、getByName、getByAge，参数应该改成一个值对象。



聚合

一个关联对象的集合。将其作为一个单元来处理数据更改。



领域、子域、界限上下文、上下文映射，这些是 DDD 的战略设计。

实体、值对象、聚合、事件溯源是 DDD 战术设计。



多搞事情，做失败了比不做好，实在担心就硬上，失败了会带来思考，逃避了只会给自己打上一个逃兵的烙印。