.NET 微服务实践(2)-视频教程介绍

文章声明：本文系油管上的一个系列（.NET Microservices – Full Course）教程的学习记录的第一章。不涉及营销，有兴趣看可以原视频（链接在底部）。

先决条件

• 能够基于C#建立.NET (Core) REST APIs
• 理解Docker和关联概念
• 了解在C#中进行依赖注入
• 能够使用Async/Await

材料/工具

• VS Code Text Editor/Visual Studio
• .NET 5+
• Docker Desktop
• Account on Docker Hub
• Insomnia or Postman
• 参考硬件条件

准备Kubernetes备忘录

• Docker & Kubernetes Commands
• Kubernetes应用程序架构参考
• Kubernetes对象术语表
• 可以通过访问他的网站、通过订阅获取资料

视频教程资料

• 代码：github.com/binarythistle
• 视频资料：https://www.youtube.com/watch?v=DgVjEo3OGBI&t=878s

关于微服务

微服务的定义和特点

以下是Les Jackson的理解【为了解释这里中英文都会放上】：

• Small (2 pizza team,2 weeks to build)【pizza team是亚马逊的梗，意思就是团队要足够小，小的量化标准就是一顿饭订两个pizza就可以满足整个团队的需求】
• Responsible for doing 1 thing well【这里和单一职责很相像】
• Self-contained /Autonomous【类似单一职责的理解，不过单一职责是从功能业务去解释，这里是从封闭和不依赖的角度解释】
• Organisationally aligned【UP主的意思是，服务应当和组织逻辑关联，负责某项业务的团队就应该有唯一对应的服务，讲的是组织的责任分配；当然人员不一定，开发人员可以既属于A团队、参与A服务的开发，也属于B团队、参与B服务的开发】
• Form part of the (distributed) whole【这里强调的是每个服务间相互隔离，共同组成整体、是整体的独立部分】

微服务的优点

通过一个对单体CRM系统的观察，给出了如下的微服务benefits：

• 更容易更改部署(小型且解耦)：（Easier to change deploy (small and decoupled)）
• 可以使用不同的技术来构建：(Built to be highly replaceable swappable)
• 增强组织职责对齐：（Increased organisational ownership alignment）
• 弹性：一个服务可以中断，但不影响其它服务正常运行：（Resilient:1 service can break the,others will continue to run）
• 可伸缩：可以仅向外扩展所需的服务：（Scalable:You can scale out only the services you need to）
• 高可替换性：（Built to be highly replaceable swappable）

和单体系统对比后的微服务缺点

辩证来看，微服务相比于单体系统，也可以自身的短板：

• 实施难度高【指的是微服务边界以及多个微服务调度协同】
• 不易于分析定位故障源【可能是多个微服务相互解耦，数据不易追踪】
• 对领域知识要求高【我认为就是微服务的边界定义问题】
• 分布式网络对于系统整体网络治理的要求高
• 微服务若不做好定义、依然容易耦合

视频教程涉及的服务

The Platform Service

• 作为“资产登记”的工作
• 跟踪和关联公司内全部的平台和系统
• 由基础架构团队构建
• 面向的用户包括：
  • 基础设施团队
  • 技术支持团队
  • 工程师团队（开发人员）
  • 会计
  • 采购

The Commands Service

• 作为针对给定平台的“指令库”功能扩展
• 在自动化支持流程方面提供帮助
• 由技术支持团队构建
• 面向的用户包括：
  • 技术支持团队
  • 基础设施团队
  • 工程师团队（开发人员）

解决方案架构

整个解决方案架构的要点：

• 平台服务依赖SQL Server做数据持久化；指令服务考虑效率则直接使用内存数据库
• 两个服务被置于内网中，外部应用通过API Gateway、以RESTFul API的方式对其进行访问
• 平台服务通过HTTP协议，在内网中访问指令服务暴露的RESTFul API
• 指令服务有两种方式访问平台服务：
• 基于消息总线，以通知/订阅的方式获取平台服务的更新（异步/同步）
• 通过gRPC访问平台服务（但是这种情况有个服务会有一定的耦合）

服务的架构

平台服务的架构

架构要点：

• 服务内部有一层仓储层，通过DBContext【我平常用EntityFramework，本质上也可以DBContext认为是一层，只是使用时无感】和数据库通信。DBContext和数据库之间是Model和Entity之间的转化、仓储层和DBContext之间是Model和DTO转化。【盲猜可能用Code First】
• 服务对外暴露Controller层、它可以访问仓储层，在内网中通过HTTP Request/Response进行通信
• 服务同时有一个调用服务，通过HTTP Client调用指令服务
• 服务还允许指令服务通过gRPC服务绕过Controller层、直接访问仓储层
• 以上服务和外部的通信都是同步消息，但是服务作为Publisher会以异步消息的方式发送消息到消息总线

指令服务架构

架构要点：

• 服务内部以及对外暴露服务的设计和平台服务相同
• 服务借助gRPC Client可以直接访问平台服务的仓储层
• 服务同时订阅消息总线，作为Subcriber接收平台服务的更新
• 以上服务和外部的通信都是同步消息

---

参考链接

• Youtube视频链接