.NET 微服务实践(1)-教程介绍

李嘉图正在调试
190 阅读4分钟

本文系油管上一个系列教程的学习记录第一章，原链接是.NET Microservices – Full Course

先决条件

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

准备工作

  • VS Code Text Editor/Visual Studio
  • .NET Core 6.0以上
  • Docker Desktop
  • Account on Docker Hub
  • API接口调试工具，如Insomnia或者Postman

准备Kubernetes常用命令

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

视频教程资料

关于微服务

微服务的定义和特点

以下是Up主的理解：

  • 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【这里强调的是每个服务间相互隔离，共同组成整体、是整体的独立部分】

微服务的优点

  • Easier to change deploy (small and decoupled）【更容易更改部署（小型且解耦）】
  • Built to be highly replaceable swappable【可以使用不同的技术来构建】
  • Increased organisational ownership alignment【增强组织职责对齐】
  • Resilient: 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【高可替换性】

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

1-4 微服务和单体系统对比.png 辩证来看，微服务相比于单体系统，也有自身的短板：

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

视频教程涉及的服务

The Platform Service

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

The Commands Service

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

解决方案架构

1-7 整体架构.png 整个解决方案架构的要点：

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

服务的架构

平台服务的架构

1-8 平台服务架构.png 架构要点：

  • 内部有一层仓储层，通过DBContext和数据库通信。DBContext和数据库之间是Model和Entity之间的转化、仓储层和DBContext之间是Model和DTO转化。
  • 最终向集群外部暴露Controller层、集群外部通过HTTP协议进行访问，Controller层可以访问仓储层。
  • 实现一个调用服务，通过HTTP协议调用指令服务。
  • 允许指令服务通过gRPC服务绕过Controller层、直接访问仓储层。
  • 以上的通信都是同步消息机制，还实现了异步消息机制——平台服务作为Publisher会以异步消息的方式发送消息到消息总线

指令服务架构

1-9 指令服务架构.png 架构要点：

  • 内部以及对外暴露接口的设计和平台服务相同
  • 借助gRPC Client可以直接访问平台服务的仓储层
  • 以上服务和外部的通信都是同步消息，还实现了异步消息机制——订阅消息总线，作为Subcriber接收平台服务的更新
avatar
文章
阅读
粉丝