[.Net]使用Soa库+Abp搭建微服务项目框架（四）：动态代理和RPC

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

微服务原理

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

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

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

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

 

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

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

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

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

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

第一

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

第二

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

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

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

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

 

（使用PostMan调试微服务）

动态代理与RPC

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

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

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

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

 

 

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

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

接口描述配置

在SoaService属性中设置创建时间，创建人员，备注等，以供服务治理提供信息

在微服务Service1.Host项目中的appsettings.json中，配置如下： 

{
  "SoaServer": {
    "Name": "Service1",
    "Ip": "127.0.0.1",
    "Port": "8007",
    "Transport": "Http",
    "AssemblyNames": "Soa.Sample.IService1,Soa.Sample.Service1"
}

在微服务Service2.Host项目中的appsettings.json中，配置如下： 

{
  "SoaServer": {
    "Name": "Service2",
    "Ip": "127.0.0.1",
    "Port": "8008",
    "Transport": "Http",
    "AssemblyNames": "Soa.Sample.IService2,Soa.Sample.Service2"
}

Service1与Service2的抽象层分别添加SoaServiceRoute标签，方法添加SoaService标签：

IService1Manager.cs

namespace Soa.Sample.IService1
{
    [SoaServiceRoute("soa_api/service1")]
    public interface IService1Manager : ISoaService
    {
        [SoaService(CreatedBy = "linxiao", Comment = "get type by main id")]
        public string GetType(long mainId);

}

}

IService2Manager.cs 

namespace Soa.Sample.IService2
{
    [SoaServiceRoute("soa_api/service2")]
    public interface IService2Manager : ISoaService
    {
        [SoaService(CreatedBy = "linxiao", Comment = "get num by main id", EnableAuthorization = true)]
        public int GetNum(long mainId);

}

}

设置完成后：

客户端访问127.0.0.1:8007/soa_api/service1/GetType 将调用Service1的GetType方法。

客户端访问127.0.0.1:8008/soa_api/service2/GetNum 将调用Service2的GetNum方法。

再次调用GetExtends方法，我们已经拿到想要的值

 

结语

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

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

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

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

项目地址

MatoApps/Soa (github.com)

​