XIAOSUO 记录个人学习的足迹

摘要：一、云原生介绍 概念 什么是云原生：云原生是一种软件开发的方法论，通俗来说就是在云计算环境中构建和运行应用程序 云计算的特点：弹性、可扩展、高可用 云原生关键点： 容器化 微服务 动态管理 CI/CD 弹性（容错机制） 服务网格 容器编排工具 监控平台（指标、链路、日志） 云原生开发与微服务开发 理念（云原生：云计算为基础；传统：固定的硬件） 架构（云原生：微服务、Serverless；传统：单机架构） 开发流程（云原生：CI/CD；传统：瀑布模型（没有自动化)） 基础设施（云原生：通过代码管理依赖资源、自动配置；传统：事先准备、手动配置） 服务发现通信（云原生：环境中自带服务发现；传统：Consul、自己实现、提前准备、依赖硬编码、配置文件） 监控和日志（云原生：环境中准备好了各种监控、日志、链路追踪；传统：过于依赖外部组件） 资源利用率（云原生：动态调整资源；传统：资源分配不灵活） 开发环境和生产环境 云原生概要已经提出很久了，k8s可以说就是上就是一个云原生环境。 我在2019年的时候就开始带团队成员来是公司的微服务转型，那个时候都是自己手撸k8s环境，各种中间件集群也是自己搭建的。 那个时候云原生环境确实不好，虽然各大云平台都提供直接的paas产品，但很多收费都较贵，最终还是自己搭建。 更重要的时候本地开发时虽然安装的docker版本，提供了mini k8s环境，但是开发和部署的环境还是不一样的。 二、Asprise介绍 如果能有一个让开发和部署都是云原生的，开发的时候不需要自己去安装mysql，redis；同时开发的时候也不需要知道最终部署的是阿里云，还是微软云。只要开发环境是基于云原生的，开发环境拥有云原生的特性，比如监控、日志、链路追踪。部署的时候只需要提供对应的云产品的产品就能让系统跑起来，这种跑起来的方式，可能就是提供一个连接字符串就可以了。如果有这样的环境，那云原生开发将变得简单很多。 对的，这就是我们当前的明星出场的时候了。 .NET Aspire是NET 8.0 LTS提出的一套开发工具，它的作用就是构建和运行云原生应用程序。 特点： Dashboard - 中心化的应用监控和探查：F5 启动 .NET Aspire可显示服务的统…… 阅读全文

摘要：上一篇我们介绍了本项目的基础架构，实际上共享项目里面还有很多内容并没有介绍。这是因为在没有具体业务前，光谈抽象类并不是很好理解，因此除了领域模型的规范和通用EFCore的实现外，其他的通用共享类都放到具体的业务中讲。 接下来，本次的出题就开始直接进入业务实现了，首先我们来谈第一个微服务，用户微服务。 一、用户服务领域层 因为我们整个项目采用的是基于洋葱模型的整洁架构，结合DDD的经典分层，我们的微服务基本上都分层四层。 ps：因为是培训项目，实际业务并不一定每个微服务都要采用一样的分层，实际开发中如果是小的，业务相对稳定微服务哪怕直接用文件夹来区分层次也是可以了。 在services文件夹中创建user文件夹，再创建DDM.DHT.UserService.Core类库项目，可以讲项目默认命名空间改成DDM.DHT.UserService。 接着创建Entities文件夹，再创建User.cs类，代码如下： public class User : BaseAuditEntity, IAggregateRoot { protected User() { } public User(string loginId, string phone) { LoginId = loginId; Phone = phone; Random random = new Random(); Name = Phone.Substring(0, Phone.Length - 4) + _ + random.Next(100, 999); UseAble = true; Salt = loginId.MD5EncodingOnly(); PasswordHash = 123456.MD5EncodingWithSalt(Salt); // default password is 123456 } public string LoginId { get; private set; } = null!; public string Name { get; private se…… 阅读全文

摘要： 一直以来想专心写一个基于云原生的微服务案例，但总角色要写的内容太多了。电商案例本身并不会太难，而要搭建好一整套云原生和微服务的基础设施，并不是一项轻松的工作。随着.Net Asprise的推出，再集成Dapr，开发和生产几乎可以保持一样的环境了。这让我惊喜，曾经我们手动搭建k8s，手动配置集群以及可以成为历史，我们需要的就是使用这些工具，重新把核心回归到业务上来。 ​ 正好新公司也是做电商业务的，于是我终于决定开始写一套云原生电商微服务的案例。一方面可以学习Asprise和Dapr的相关知识，也是一次属性电商核心业务的机会。 ​ 这次的内容会写得比较细，目标是把这个项目当成一个培训项目来写。让不了解云原生、不了解微服务和不了解电商业务的人，也能看得懂该项目。 一、DDD DDD相关的文章以及很多了，我在几年前也写过一个DDD的学习系列，本文就只是做个总结，毕竟微服务是离不开DDD的。 解决什么问题 问题域 需求分析 分析理解复杂业务领域问题 准确反映业务语言 领域分析概念 领域 子域 核心域、通用域和支撑域 限界上下文 领域建模概念 实体与值对象 聚合与聚合根 领域事件 领域服务 仓储 工作单元模式 规约 应用服务 防腐层 领域驱动设计 CQRS： 命令与查询分离，作为一种战术办法，是实现DDD建模领域的最佳途径之一。 充血模型： 让模型自带业务逻辑，业务属性的改变只有模型自身可以操作。 二、整洁架构 核心原则 独立于框架：整洁架构的系统核心业务逻辑不依赖于具体的软件框架，业务逻辑部分都能够独立运行。这样在框架更新或者替换时，对核心业务的影响最小。 可测试性：架构设计使得业务规则可以很方便地被测试。因为业务逻辑是独立于外部组件（如数据库、用户界面等）的，所以可以使用单元测试来验证业务规则的正确性。比如，在一个电商系统中，“计算商品折扣”的业务规则可以通过提供模拟的商品价格数据来进行单元测试，而不需要真正地连接数据库或者启动整个用户界面。 独立于UI（用户界面）：业务逻辑与用户界面相互独立。这意味着可以方便地替换用户界面，比如从一个命令行界面转换为图形界面，或者从Web界面转换为移动应用界面，而不会影响到业务逻辑。 独立于数据库：系统的核心不依赖于数据库的类型…… 阅读全文