​

上一章我们完成了小项目的面向服务体系改造，你或许一直在思考一个问题。为什么要将业务独立成微服务？

以一个健康医疗系统为例， 这个系统包含了用户模块，问卷的发放与填写，图表显示，报表生成与查看，患者管理等功能，传统的架构如下：

​

随着项目规模的增长，在开发过程中会发现如下问题：

1. 各模块之间耦合严重，比如：报表模块引用了问卷，用户，随访，患者管理等几乎所有模块，难以维护
2. 间接引用的情况过多，导致项目分层不明确，容易产生引用分歧，难以维护

目前做的就是解耦各个模块之间的强关联状态，通过第一章提到的上下文边界划分方式，我们大致可以将系统的架构改造如下：

 

​

通过调用者和实现者共同引用抽象的方式，解耦程序集之间的引用

各微服务之间用RPC方式通信，实现各服务之间独立运行，独立部署，互不干涉 

我们了解一下微服务的概念：

1. 将单一应用程序划分成多个小的服务，每个服务围绕单一业务进行构建
2. 每个服务可独立部署，独立运行，独立测试
3. 服务之间采用轻量级的通信机制互相沟通 。

在回到我们的代码上来。讨论一下改造之后的项目特性：

第一

• 整体业务用上下文边界划分方式，围绕单一业务模型构建的领域模型，领域层互不干涉
• Host服务仅依赖自身的领域层，而领域层也是单一职责构建的，Host服务互不干涉
• 每个Host服务可以配置独立的数据库连接字符串，数据互不干涉

第二

• 各Host项目可以配置端口和ip，可独立部署至不同的网络环境。
• 各Host都独立生成exe文件，可以独立运行。

我们来模拟一下其中一个服务崩溃的场景：假设将Service1Host和Service2 关掉，再次请求GetExtends​

 可以发现主服务是可用的，只是type和num拿不到值而已，这证明了调用者不依赖于其他服务而保持独立运行。

• 若是Http方式参与远程过程调用，可以用浏览器，或者PostMan调试各项目

 

​

（使用PostMan调试微服务）

 第三

• RPC（Remote Procedure Call）远程过程调用，简单的理解是一个节点请求另一个节点提供的服务，整个项目是使用Http协议实现RPC通信。

下面来介绍一下Soa库如何实现RPC通信的：

首先Soa库将所有继承ISoaService的类，用SyntaxFactory生成代理类对象，并生代理类程序集（名称为目标程序集+Proxy），它的字节流加载进内存中，这些代理类中的成员对象与目标类型一模一样。同样继承了IServiceManager。

但是实现方式改为调用SoaClient，通过反编译工具可以看到，代理类的结构

​

 ​

 

当客户端调用代理类中的方法，它将生成目标方法的Id（一般是类名＋方法名）、参数内容、目标方法的描述（签名类型，返回值等内容），之后根据此映射的ip地址和端口号，打包发送至服务端。

服务端接受到报文之后，通过ServiceId找到目标方法的描述，用反射的方式Invoke目标方法，并将返回内容序列化后打包至响应报文

需要注意的是，此时的架构优化并不是传统意义上的微服务，而是一种面向服务体系的架构

传统意义上的微服务，应该基于去中心化的思想而构建，类似下图：

​

它包含一个网关，由它来路由请求到各个服务。由它进行鉴权认证，和健康监测。

意味着这个小项目和Soa库还有一段路要走。有时间还会继续更新这个系列文章，欢迎留言或评论。

​