一、微服务

1、为什么使用微服务？

    1）单体巨无霸系统带来的问题

        a. 编译、部署困难

        b. 代码分支管理困难

        c. 数据库连接耗尽

        d. 新增业务困难

    2）拆分，将大应用拆分为多个小应用

        a. 横向拆分：将公共的业务拆分出来，复用于其他业务

        b. 纵向拆分：将大应用拆分多个小应用

二、微服务架构落地的支撑--微服务框架

1、微服务框架的起源--Web Service

    1）三个角色：

        a. Service Provider：服务提供者

        b. Service Requester：服务消费者

        c. Service Broker：服务注册中心

    2）不足之处：

        a. 臃肿的注册于发现机制

        b. 低效的XML序列化手段

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

        d. 复杂的部署与维护手段

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

2、微服务框架中的关键点

    1）服务的注册与发现：

    2）服务间的远程调用：

    3）失效转移--高可用：

        a. 服务集群化部署，实现服务的高可用

        b. 调用某个服务实例失败时，调用者需要尝试换一个服务实例

    4）负载均衡：

        a. 服务集群化部署后，需要使用负载均衡的访问方式

        b. 调用者按照负载均衡策略访问服务实例

    5）高效远程通信--通信协议：

        a. HTTP协议相对低效，需要自己实现一套高效的通信协议

    6）对应用最少侵入

        a. 业务开展服务化的过程是渐进的，所以微服务框架要减少对业务的影响，方便业务的演进

    7） 服务的版本管理

3、微服务框架案例分析--Dubbo



4、Service Mersh

    1）微服务框架存在的问题

        a. 服务的调用者需要自己负责服务的发现和调用（通过代理对象）

        b. 服务的调用者需要自己实现失效转移处理（通过代理对象）

        c. 服务的调用者需要自己实现负载均衡的调用处理（通过代理对象）

        d. 服务的调用者需要自己决定远程调用服务的方式和使用协议（通过代理对象）

        -->服务调用方为了调用服务，需要做很多的事情，而且这些事情对不同的调用方而言，是相似的、重复的！

    2）Service Mersh做的事情

        a. Service Mersh构建了一个用于服务间通信的基础设施层，用于处理服务间的通信

        b. 相当于把代理对象抽离出来，构成了一个中间层，原来代理对象做的事情，都交给了Service Mersh

        c. Service Mersh的Sidecar模式



三、如何落地微服务架构

1、微服务落地的关键点，不是技术，而是要理顺业务，梳理业务的边界

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

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

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

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

    -->倒三角模型:

2、微服务落地时的一些关注点

    1）事件溯源

        a. 将用户的每次状态变化都记录到事件日志中，并按时间序列进行持久化存储

        b. 可复现用户的状态变化，进行复核审计

        c. 可在此基础上实现分布式事务

    2）断路器

        a. 阻断对故障服务的调用，避免响应延迟或失败率增加，导致请求的阻塞和资源消耗

    3）服务重试&调用超时

    4）分布式链路追踪

3、微服务落地时的一些实践

    1）CQRS

四、微服务网关

1、基于网关的微服务架构

2、网关的作用

    1）统一接入

    2）流量管控与容错

    3）协议适配

    4）安全防护

3、网关中的技术

    1）网关管道技术：责任链模式

    2）异步网关：Servelrt3

4、网关分类

    1）开放平台网关

    2）安全网关

五、微服务发展小结

1、单体应用->微服务：解决发布、部署困难的问题

2、微服务->平台化：构建通用服务、服务复用

3、平台化->中台化：微服务定义了业务规范。业务系统依赖微服务，实现具体的业务

六、领域驱动设计--DDD

1、为什么需要DDD

    1）软件只有需求分析，没有真正的设计，系统没有一个统一的领域模型维持其内在的逻辑一致性

    2）功能特性并不是按照领域模型内在的逻辑设计，而是按照个色人等自己的主观想象设计

    3）以上两点导致随着需求的零散开发和变更，项目变的越来越复杂和难以维护

2、DDD是什么

    1）传统开发模式：事务脚本型、面向过程的编程；DDD：领域模型、面向对象的编程

    2）贫血模型 VS 充血模型

3、怎么做DDD

    1）领域：明确产品要做的事情、范围、边界

    2）子域：整个领域要做的事情太多、太大，需要拆分，拆分成多个子域

        a. 如何划分子域？划分的规则？

    3）界限上下文

        a. 和子域具有一对一的关系，用来控制子域的边界        b. 在界限上下文划定的边界中，任何领域对象都具有唯一的特定含义，不存在二义性

    4）上下文映射图：描述子系统或模块之间的交互合作

    5）实体

    6）值对象

        a. 实体 VS 值对象：对实体而言，属性值相同并不表示是同一个对象，一定需要通过ID值进行区分；对值对象而言，属性值相同一定表示同一个对象

    7）聚合

4、DDD相关架构

    1）分层架构

    2）六边形架构

5、DDD战略设计与战术设计

    1）战略 VS 战术

        a. 领域、子域、界限上下文、上下文映射图，这些是战略设计        b. 实体、值对象、聚合、CQRS、事件溯源，这些是战术设计

    2）战略的作用

       a. 通过战略设计，划分模块和服务的边界及依赖关系，对微服务架构的设计至关重要