[.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)

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

https://blog.matoapp.net/posts/8090d4cd/

作者

林晓lx

发布于

2022-01-15

更新于

2024-09-11

许可协议

评论