标签：Soa 服务 独立 Abp Host 模块 Net RPC
上一章我们完成了小项目的面向服务体系改造，你或许一直在思考一个问题。为什么要将业务独立成微服务？
以一个健康医疗系统为例， 这个系统包含了用户模块，问卷的发放与填写，图表显示，报表生成与查看，患者管理等功能，传统的架构如下：
随着项目规模的增长，在开发过程中会发现如下问题：
- 各模块之间耦合严重，比如：报表模块引用了问卷，用户，随访，患者管理等几乎所有模块，难以维护
- 间接引用的情况过多，导致项目分层不明确，容易产生引用分歧，难以维护
目前做的就是解耦各个模块之间的强关联状态，通过第一章提到的上下文边界划分方式，我们大致可以将系统的架构改造如下：
通过调用者和实现者共同引用抽象的方式，解耦程序集之间的引用
各微服务之间用RPC方式通信，实现各服务之间独立运行，独立部署，互不干涉
我们了解一下微服务的概念：
- 将单一应用程序划分成多个小的服务，每个服务围绕单一业务进行构建
- 每个服务可独立部署，独立运行，独立测试
- 服务之间采用轻量级的通信机制互相沟通 。
在回到我们的代码上来。讨论一下改造之后的项目特性：
第一
- 整体业务用上下文边界划分方式，围绕单一业务模型构建的领域模型，领域层互不干涉
- 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库还有一段路要走。有时间还会继续更新这个系列文章，欢迎留言或评论。
标签：Soa,服务,独立,Abp,Host,模块,Net,RPC 来源： https://www.cnblogs.com/jevonsflash/p/15806231.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。