上一章我们完成了小项目的面向服务体系改造，你或许一直在思考一个问题。为什么要将业务独立成微服务？
微服务原理
以一个健康医疗系统为例， 这个系统包含了用户模块，问卷的发放与填写，图表显示，报表生成与查看，患者管理等功能，传统的架构如下：
随着项目规模的增长，在开发过程中会发现如下问题：
- 各模块之间耦合严重，比如：报表模块引用了问卷，用户，随访，患者管理等几乎所有模块，难以维护
- 间接引用的情况过多，导致项目分层不明确，容易产生引用分歧，难以维护
目前做的就是解耦各个模块之间的强关联状态，通过第一章提到的上下文边界划分方式，我们大致可以将系统的架构改造如下：
通过调用者和实现者共同引用抽象的方式，解耦程序集之间的引用
各微服务之间用RPC方式通信，实现各服务之间独立运行，独立部署，互不干涉
我们了解一下微服务的概念：
- 将单一应用程序划分成多个小的服务，每个服务围绕单一业务进行构建
- 每个服务可独立部署，独立运行，独立测试
- 服务之间采用轻量级的通信机制互相沟通 。
在回到我们的代码上来。讨论一下改造之后的项目特性：
第一
- 整体业务用上下文边界划分方式，围绕单一业务模型构建的领域模型，领域层互不干涉
- 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库还有一段路要走。有时间还会继续更新这个系列文章，欢迎留言或评论。
项目地址
文章来源: 博客园
- 还没有人评论，欢迎说说您的想法！
客服
