微服务架构-服务本身的设计、维护与治理

传统架构的问题

• 编译部署困难

• 代码分支管理复杂

• 数据库连接耗尽

• 新增业务困难

解决办法：

拆分，将模块独立部署，降低系统耦合性。

微服务框架需求

失效转移（Fail Over）：

• 对于大型网站的微服务而言，即使是很少访问的简单服务，也需要集群部署，同时微服务框

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

负载均衡：

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

实现负载均衡。

高效的远程通信：

• 对于大型网站，核心服务每天的调用次数会达到数以亿计，如果没有高效的远程通信手段，

服务调用可能会成为整个系统性能的瓶颈。

对应用最少侵入：

• 网站技术是为业务服务的，是否使用微服务需要根据业务发展规划，微服务也需要渐进式的

演化，甚至会出现反复，即使用了微服务后又退回到集中式部署，微服务框架需要支持这种

渐进式演化和反复。当然服务模块本身需要支持可集中式部署，也可分布式部署。

版本管理：

• 为了应对快速变化的需求，服务版本升级不可避免，如果仅仅是服务实现升级，那么这种升

级对服务请求者而言是透明的，无需关注。但是如果服务的访问接口发生变化，就需要服务

请求者和服务提供者同时升级才不会导致服务调用失败。企业应用系统可以申请停机维护，

同时升级接口，而网站服务不可能中断，需要服务提供者先升级接口，并同时提供历史版本

的服务供请求者调用，当请求者访问接口升级后才可以关闭历史版本服务。



微服务框架架构

spring cloud架构图



Service Mesh 服务网格

Service Mesh 是一个基础设施层，用于处理服务间的通信，通常表现为一组轻量级网络

代理，他们与应用程序部署在一起，而对应用程序透明。



微服务架构落地策略和思路

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

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

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

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



微服务网关的技术架构



领域驱动设计

为什么需要DDD

很多项目的实际情况：

• 用户或者产品经理的需求零零散散，不断变更。

• 工程师在各处代码中寻找可以实现这些需求变更的代码，修修补补。

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

致性。

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

项目时间一长，各种困难重重，需求不断延期，线上 bug 不断，管理者考虑是不是要推

倒重来，而程序员则考虑是不是要跑路。

DDD 战略设计

领域是一个组织所做的事情以及其包含的一切，通俗地说，就是组织的业务范围和做事方式，也是软件开发的目标范围。领域驱动设计就是从领域出发，分析领域内模型及其关系，进而设计软件系统的方法。

子域

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

限界上下文

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



课后作业