第十周总结

本周的主要的内容是模块拆解，模块拆解可大可小。从单体架构来看是拆成多个模块，从微服务的角度来看是拆成多个服务。在拆解的过程中，需要关注的是服务本身，而非所谓的拆解技术栈。不要为了微服务而进行服务拆解。为了更好的进行模块拆解，业内比较推崇领域驱动建模设计。在领域专家的指导下深入挖掘现实世界的问题本质从而建立领域模型，进而得到解决方案。

微服务

微服务的出现主要为了解决单体应用太臃肿导致的一系列问题。

大型单体应用的弊端

• 编译、部署困难

• 分支维护困难

• 数据库连接耗尽

• 新增业务困难

研发过程为了解决单体应用的上述弊端，主要解决方案是从业务本身出发，拆分部署独立应用。通常可以从垂直方向和水平方向考虑。

垂直拆分是根据业务属性以及功能的耦合性进行划分，把大应用拆成各种独立小应用，新增业务可以考虑独立部署以快速响应业务需求。

水平拆分则是考虑将复用性较强的功能进行拆分，部署一套，类似中台概念。

Web Service

早期采用 Web Service 体系来实现微服务以及分布式服务；即服务提供者以 WSDL 向注册中心描述自身提供服务的接口属性，注册中心采用 UDDI 发布服务提供者提供的服务；服务消费者从注册中心检索到服务信息后，通过 SOAP 和服务提供者通信。其有固有的弊端：

• 臃肿的注册于发现机制

• 低效的 XML 序列化手段

• 开销较高的 HTTP 远程通信

• 复杂的部署与维护

显然，这与互联网应用要求的高并发、高性能、高可用、易部署与易维护要求不一致。

服务治理

当一个大型单体应用拆分成多个微服务，微服务之间通过协作完成业务需求，可简单视作分布式应用，这其中涉及到服务治理，主要如下：

• 服务注册、服务发现、服务调用

• 负载均衡（服务动态增减）

• 失效转移（failover）确保服务高可用

• 高效远程通信

• 应用侵入性

• 版本管理

当前 JAVA 方法微服务的解决方案有 Spring Cloud，利用 Spring Cloud 的相关组件快速搭建一套微服务体系。

Service Mesh

service mesh 是一套基础层，用来处理服务间的通信，通常表现为一组轻量级网络代理，它们与应用部署一起又对应用透明。当前 sidecar 作为 service mesh 的一种落地方案，通过增加一层虚拟层，帮助应用做服务治理。

微服务落地原则

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

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

• 基于业务和系统逻辑进行微服务重构

• 从提升服务复用、明确服务边界、提升分布式集群性能的角度出发作为微服务目的

网关

微服务体系中网关作为流量入口，需要确保其高可用。网关作为服务转发和聚合，通常与业务耦合性较弱。

• 统一接入

• 安全防护鉴权

• 协议适配

• 流量控制与容错

开放平台网关

开放平台网关是提供给第三方外部用户的服务。主要做认证、授权、安全、审计，如微信开放平台。

• API 接口

• 协议转换

• 安全

• 审计

• 路由

• 流程

DDD

DDD 即领域驱动设计，是领域模型工具化方法论的一个扩展。DDD 主要是作为指导我们微服务落地，如何更好的关注服务本身，进行服务拆分。

项目现状

• 需求零零散散，快速迭代，不断变更

• 工程师基于需求对工程缝缝补补

• 软件系统只有需求，没有设计。系统没有一个统一的领域模型维持其内在逻辑一致性

• 开发过程中功能特性并非按照领域模型内在逻辑联系设计，而是根据个人主观设计

贫血模型 & 充血模型

在业务开发中，service、dao 这些对象只有方法没有数值成员变量，以方法调用传递数值对象，通常称为贫血模型。贫血模型会导致一个方法随着业务功能不断的膨胀。

领域模型设计中的对象既有数据又有逻辑计算，从面向对象的角度来看，领域模型才是真正的面向对象。领域模型是合并了行为和数据领域对象模型，通过领域模型对象的交互完成业务逻辑的实现，领域模型也称为充血模型。

DDD 术语

• 领域与子域

• 限界上下文

• 上下文映射

• 实体与值对象

• 聚合与聚合根