XIAOSUO 记录个人学习的足迹

摘要：用户服务开发好之后，本来是要先介绍认证中心的。由于写了几篇了还没有看到电商业务的痕迹，于是今天先介绍品类微服务，做一期业务方面的设计与实现，下回再介绍认证中心。 一、品类与品牌 任何一个电商平台，品类是最先存在的一个业务功能。比如京东它最开始的定位就一个家电行业的垂直电商，后来最大了才有更多的其他品类。而现实中，可能会真正存在一个专门的品类管理处的部门，他们的职责可能是研究公司战略方向的。品类微服务不仅仅只是一个名称，它可能有专门的单独品类首页，有专门的营销策略，商品的存活的、推荐等等，因而品类对于电商业务来说是非常重要的。 品牌决定了电商平台具体卖什么东西，不同的平台品牌同意可能有不同的业务。比如营销方式、合作模式、分成方式等等。 对电商平台访问者来说，他们可能只是搜索商品，选择满意的商品后就下单了。他们知道品类和品牌的存在，但不会考虑到品类和品牌还有那么多具体的后台业务逻辑。而对于电商平台来说，品类和品牌是真正存在的可能还是非常复杂的业务。 接着我们来访问一下京东网站： 可以看到左侧有一个很大的品类选项。展开品类后又有二级或三级选择。随便点击一个三级品类选项后，可以看到URL地址：https://list.jd.com/list.html?cat=652,654,834 cat对应的值就是一个三级分类，分别提供了3个id值。 接着我们再在搜索框上随便搜个结果，可以看到品牌的筛选筛选项，品牌下面还会动态出现一些跟搜索的内容相关参数的筛选项，这些选择项都是动态的。比如我们搜索手机，出现的选择项是CPU、内存，电池，而我们搜索衣服时，出现的选择项变成了颜色、尺码、适用年龄。 根据分析京东的页面，我们大致可以了解到几个信息： 京东的品类有3级分类。 选择具体的品类后，才有关联的品牌。比如选择衣服后才有衣服对应的品牌，选择手机后才有手机的品牌。 筛选项是根据选择的品类后，动态出现的，也就是说筛选项会根据不同的品类有不同的内容，甚至还有高级选项。 于是我们就有了电商平台第一个业务相关的微服务品类微服务： 为什么品类服务要单独出来了，合并到商品服务里面不行吗？ 微服务的划分没有标准答案，业务不是很复杂时，可以把品类服务合并到商品服务里面。而我们这里单独出来，是因为电商业务最…… 阅读全文

摘要：一、云原生介绍 概念 什么是云原生：云原生是一种软件开发的方法论，通俗来说就是在云计算环境中构建和运行应用程序 云计算的特点：弹性、可扩展、高可用 云原生关键点： 容器化 微服务 动态管理 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界面转换为移动应用界面，而不会影响到业务逻辑。 独立于数据库：系统的核心不依赖于数据库的类型…… 阅读全文

摘要：#本方案定义公司实施微服务的开发标准，规定了源码的分层结构、各层次的编码规范；单个微服务采用CQRS架构；微服务间使用gRCP通信；并提供了微服务需要的基础设施，如ELK，下面具体说明： 分层 领域层 基础设施层 应用层 共享层 注意： 领域模型专注业务的设计，不依赖仓储等基础设施层 基础设施的仓储层仅负责领域模型的取出和存储 使用CQRS 模式设计应用层 Web API 是面向前端的交互的接口，避免依赖领域模型 定义Entity,区分内在逻辑和外部行为 将领域模型字段的修改设置为私有 使用构造函数表示对象的创建 使用具有业务含义的动作来操作模型字段 领域模型负责对自己数据的处理 领域服务或命令处理者负责调用领域模型业务动作 工作单元模式(UnitOfWork) 使用同一上下文 跟踪实体的状态 保障事务一致性 使用EF实现仓储 领域事件来实现模块解耦 由领域模型内部创建事件 由专有的领域事件处理类处理领域事件 根据实际情况来决定是否在同一事务中处理（如一致性、性能等因素） 集成事件解决跨服务最终一致性 集成事件是跨服务的领域事件 集成事件一般由领域事件驱动触发 不通过事务来处理集成事件（实现最终一致性） 仅在必要的情况下定义和使用集成事件 用RabbitQM来实现EventBus MediatR实现CQRS IMediator IRequest、IRequest​ IRequestHandlerin TRequest, TResponse INotification INotificationHandler​ gRPC实现内部服务间通信 gRPC的特点： 提供几乎所有主流语言的实现，打破语言隔阂 基于HTTP/2 ，开放协议，受到广泛的支持，易于实现和集成 默认使用Protocol Buffers 序列化，性能相较于RESTful Json 好很多 工具链成熟，代码生成便捷，开箱即用 支持双向流式的请求和响应，对批量处理、低延时场景友好 NET 生态对gRPC 的支持情况 提供基于HttpClient 的原生框架实现 提供原生的ASP.NET Core 集成库 提供完整的代码生成工具 Visual Studio 和Visual Stuido Code 提供proto 文件的智能提示 网关区分场景与职责 Poll…… 阅读全文

摘要：k8s介绍 什么是k8s k8s是一个舵手，专门用来进行给docker掌管方向的，换句话说，就是用来控制docker运行容器的 和docker 是一样的功能。所以就有一个概念cluster 为什么要使用k8s 因为当docker容器异常的时候，docker无法将容器进行重启，如果容器数量比较大 swarm 优点 架构简单，部署运维成本低 docker swarm 集群模式由于原生态集成到docker-engine中，所以首先学习成本低，对于使用docker-engine 1.12版本及以上可以平滑过渡，service服务可以满足动态增减容器个数，同时具备自身的负载均衡，swarm管理者多台设定保证了机器在出错后有一个良好的容灾机制 启动速度快 swarm集群只会有两层交互，容器启动是毫秒级 swarm缺点 1 无法提供更精细的管理 swarm API兼容docker API，所以使得swarm无法提供集群的更加精细的管理 2 网络问题 在网络方面，默认docker容器是通过桥接与NAT和主机外网络通信，这样就出现2个问题，一个是因为是NAT，外部主机无法主动访问到容器内（除了端口映射），另外默认桥接IP是一样的，这样会出现不同主机的容器有相同的IP的情况。这样两容器更加不能通信。同时网络性能方面，有人测试经过桥接的网络性能只有主机网络性能的70%。当然以上问题可以通过其他工具解决，比如用 Flannel 或者 OVS网桥 3 容器可靠性 在容器可靠性方面，相较于Kubernetes的Replication Controllers可以监控并维持容器的生命，swarm在启动时刻可以控制容器启动，在启动后，如果容器或者容器主机崩溃，swarm没有机制来保证容器的运行。 kubernetes优点： 1 管理更趋于完善稳定 kubernetes 集群管理更趋于完善稳定，同时pod功能上比swarm的service更加强大 2 健康机制完善 Replication Controllers可以监控并维持容器的生命 3 轻松应对复杂的网络环境 kubernetes默认使用Flannel作为overlay网络。 Flannel是CoreOS 团队针对 Kubernetes 设计的一个覆盖网络（OverlayNetwork）工具，其目的在于帮助每一个使用 Kuberen…… 阅读全文

摘要： Docker版本 17.03版本之后 1、CE（Community Edition: 社区版） ---- 免费 2、EE（Enterprise Edition: 企业版）---- 收费 windows 安装 条件 1、windows 10 2、开启Hyper-V 3、安装Toolbox 最新版 Toolbox 下载地址： https://www.docker.com/get-docker 点击 Download Desktop and Take a Tutorial，并下载 Windows 的版本 linux安装 1. centos7.0 以上的版本 ​ 2. 安装docker 版本仓库 docker版本 ​ 2.1 设置仓库 ​       sudo yum install -y yum-utils device-mapper-persistent-data lvm2 ​ 2.2 稳定仓库 ​     sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo ​ 3. 安装docker(默认安装最新版本) ​ sudo yum install docker-ce docker-ce-cli containerd.io ​ 如果要安装其他版本 ​       要安装特定版本的 Docker Engine-Community，请在存储库中列出可用版本，然后选择并安装： ​       1、列出并排序您存储库中可用的版本。此示例按版本号（从高到低）对结果进行排序。 ​         yum list docker-ce --showduplicates | sort -r ​               docker-ce.x86_64 3:18.09.1-3.el7                     docker-ce-stable               docker-ce.x86_64 3:18.09.0-3.el7                     docker-ce-stable               docker-ce.x86_64 1…… 阅读全文

摘要：什么是链路监控 APM 什么是链路 在分布式系统中，完成一个功能 ，需要涉及到许多服务协作，连接这些服务的请求组合起来就是链路， 例如：就好比一台自行车，我想让自行车跑起来，必须使用链条，那么这个链条就是链路。 什么是链路监控 就是用来记录服务之间的请求过程，就是链路监控 为什么要使用链路监控 见图，微服务不使用链路监控 微服务系统正常运行，时间正常情况下，不需要使用监控中心 在微服务调用过程中比较耗时情况 2.1 如何知道是什么地方导致耗时，无法排查是哪一个节点出现了问题 在微服务调用过程中，涉及到哪些微服务情况 3.1 无法知道微服务的调用过程。 在这两个问题的情况下，所以我们需要使用知道微服务之间的调用过程和每一个微服务掉调用过程所需要的时间。 根据场景中出现的问题，来引出链路监控 那么如何解决这两种问题呢，所以出现了链路监控 链路监控框架 Cat ：大众点评开发，基于java的实时应用监控平台，包括实时应用监控，业务是监控 Zipkin ：java 开发Zipkin是Twitter开源的调用链分析工具，目前基于springcloud sleuth得到了广泛的使用，特点是轻量，使用部署简单 ：代码嵌入性强，基于中间件实现， Pinpoint：java开发 Pinpoint是韩国人开源的基于字节码注入的调用链分析，以及应用监控分析工具。特点是支持多种插件，UI功能强大，接入端无代码侵入 SkyWalking：java 开发 SkyWalking是本土开源的基于字节码注入的调用链分析，以及应用监控分析工具。特点是支持多种插件，UI功能较强，接入端无代码侵入。目前已加入Apache孵化器。全链路追踪，配置极其简单。没有任何代码入侵。 Naver的Pinpoint、Apache的HTrace、阿里的鹰眼Tracing、京东的Hydra、新浪的Watchman，美团点评的CAT，skywalking等。 根据优点和缺点(也是框架内部的一些配置和对比)进行比较得出结论 两方面考虑 结合框架特点，结合业务场景特点 所以我们选择SkyWalking 微服务系统中如何使用SkyWalking SkyWalking概念 Skywalking Agent： SkyWalking客户端，用来发送链路数据到Collecter SkyWalking Collect…… 阅读全文

摘要：什么是事物 例如：事物 所有看到的一切都是事物，不能看到的也是事物 例如：团队微服务，成员微服务，聚合微服务，网关api，认证中心等等包括类，对象 所有的事件都是事物变化的结果 大家接触事件最早就是在js 或者是c#高级特性。大家对于事件不默认，但是对于事件不是很好理解 什么是事件 事件就是指事物状态的变化，每一次事物变化的结果都称作为事件 什么是事件总线 就是用来管理所有的事件的一种机制就称作为事件总线 包括事件发布，事件存储，事件订阅，事件处理的统称 作用： 事件总线是一种机制，它允许不同的组件彼此通信而不彼此了解。 组件可以将事件发送到Eventbus，而无需知道是谁来接听或有多少其他人来接听。 组件也可以侦听Eventbus上的事件，而无需知道谁发送了事件。 这样，组件可以相互通信而无需相互依赖。 同样，很容易替换一个组件。 只要新组件了解正在发送和接收的事件，其他组件就永远不会知道. 为什么要使用事件总线 将微服务系统各组件之间进行解耦 使用业务的发展来说 事件总线框架 CAP masstransit CAP内部概念 事件 ： 就是一些状态信息 发布者：发布事件的角色 cap 订阅者：订阅消费事件的角色 cap 消息传输器：传输事件 消息存储器：存储事件 CAP存储事件消息队列类型Transport Azure rabbitmq kafaka In Memory Queue CAP存储事件持久化类型 SQL Server MySQL PostgreSQL MongoDB InMemoryStorage CAP事件监控 Dashboard 微服务系统中如何使用CAP 条件 微服务系统 RabbitMQ SqlServer CAP 步骤 微服务系统准备 微服务系统全部准备完毕 RabbitMQ准备 2.1 环境准备 Erlang下载地址：https://www.erlang.org/downloads RabbitMQ下载地址：https://www.rabbitmq.com/download.html 2.2 RabbitMQ 启动 1、在安装目录下添加可视化插件 rabbitmq-plugins enable rabbitmq_management 在安装目录下启动 rabbitmq-server 查看rabbitmq状态 …… 阅读全文

摘要：什么是配置中心 配置是用来动态修改程序执行的一种行为的机制 为什么要使用配置中心 安全性：配置跟随源代码保存在代码库中，容易造成配置泄漏。 时效性：修改配置，需要重启服务才能生效。 局限性：无法支持动态调整：例如日志开关、功能开关。 因此，分布式配置中心应运而生！ 配置中心类型方式 Apollo，java开发 ----- 运维成本比高 Apollo分为MySQL，Config Service，Admin Service，Portal四个模块，MySQL存储Apollo元数据和用户配置数据; Config Service提供配置的读取、推送等功能，客户端请求都是落到Config Service上; Admin Service提供配置的修改、发布等功能，Portal操作的服务就是Admin Service; Portal提供给用户配置管理界面;功能强大，社区活跃，但较为复杂，部署组件较多，运维成本比高 Consul, go开发 依赖：不依赖其他组件 应用内/外：属于外部应用，侵入性小 ACP原则：遵循CP原则（一致性+分离容忍） 服务注册稍慢，由于其一致性导致了在Leader挂掉时重新选举期间真个consul不可用。 版本迭代：目前仍然进行版本迭代 集成支持：支持SpringCloud K8S集成 访问协议：HTTP/DNS 雪崩保护：不支持雪崩保护 集成：SpringCloud集成，K8S集成 自动注销实例：不支持 界面：英文界面，不符合国人习惯 上手：复杂一点 Nacos,依赖：mysql ----- 依赖：mysql 应用内/外：属于外部应用，侵入性小 ACP原则：通知遵循CP原则（一致性+分离容忍） 和AP原则（可用性+分离容忍） 版本迭代：目前仍然进行版本迭代，最近的提交是几天前 集成支持：支持Dubbo 、SpringCloud、K8S集成 访问协议：HTTP/动态DNS/UDP 雪崩保护：支持雪崩保护 Spring cloud config java开发 ----- Net支持比较差 自动注销实例：支持 界面：国产服务，中文界面，符合国人习惯 上手：极易，中文文档，案例，社区活跃 Consul实际上是和Nacos比较相似的产品，虽然Consul目前的主要发展方向放在了Service Mesh，但是Consul最初支持的服务发现和配置管理，也是Naco…… 阅读全文