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界面转换为移动应用界面，而不会影响到业务逻辑。 独立于数据库：系统的核心不依赖于数据库的类型…… 阅读全文

摘要：持续集成、继续部署、继续交付 持续集成(Continuous integration) 是一种软件开发实践，即团队开发成员经常集成它们的工作， 通过每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。 每次集成都通过自动化的构建（包括编译，发布，自动化测试）来验证，从而尽早地发现集成错误。 持续部署（continuous deployment） 是通过自动化的构建、测试和部署循环来快速交付高质量的产品。 某种程度上代表了一个开发团队工程化的程度，毕竟快速运转的互联网公司人力成本会高于机器， 投资机器优化开发流程化相对也提高了人的效率，让 engineering productivity 最大化。 持续交付（英语：Continuous delivery，缩写为 CD） 是一种软件工程手法， 让软件产品的产出过程在一个短周期内完成，以保证软件可以稳定、 持续的保持在随时可以释出的状况。它的目标在于让软件的建置、 测试与释出变得更快以及更频繁。这种方式可以减少软件开发的成本与时间，减少风险。 DevOps DevOps（Development和Operations的组合词）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。 它是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。 它的出现是由于软件行业日益清晰地认识到：为了按时交付软件产品和服务，开发和运维工作必须紧密合作。 Jenkins Jenkins是实现DevOps的工具 Jenkins是一款开源 CICD 软件，用于自动化各种任务，包括构建、测试和部署软件。 Jenkins 支持各种运行方式，可通过系统包、Docker 或者通过一个独立的 Java 程序。 特点： 易于安装，只要把jenkins.war部署到servlet容器 易于配置-所有配置都通过其提供的web界面实现。 集成RSS/E-mail通过RSS发布构建结果或当构件完成是通过e-mail通知。 生成JUnit/TestNG测试报告。 分布式构建支持Jenkins能够让多台计算机一起构建/测试。 文件识别：Jenkins能够跟…… 阅读全文

摘要：什么是无服务器计算 “无服务器”是云计算中资源抽象的极致体现。从它的命名上你就可以看出，所谓“无服务器”就是想让用户感觉不到服务器的存在，这是因为有一朵巨大的云在底层进行着支撑。 如果说容器是给予了我们很大的定制空间，让你更加容易地按照自己的需要，来进行应用程序的拆分和封装；那么无服务器则是完全屏蔽了计算资源，它是在真正地引导你不再去关心底层环境，你只要遵循标准方式来直接编写业务代码就可以了。 而且在粒度上，无服务器会允许你拆分得更细致、更轻量。你甚至可以把每一个具有独立功能的函数，来作为一个单独的服务进行部署和运行。这也是为什么，在有些云计算的分类方法下，无服务器计算能够单独“开宗立派”，被称为函数即服务（Function-as-a-Service，FaaS）的原因。 各大云厂商现在都已经推出了各自的无服务器计算服务，比如 AWS 的 Lambda、阿里云的函数计算，和微软 Azure 的 Azure Functions。在国内的云厂商中，腾讯云的云函数也是在无服务器计算上投入较早、产品较为成熟的厂商。 无服务器计算是多面手 无服务器计算所能做的，可远远不止充当快速的 Web 开发工具。事件模型是无服务器的核心编程模型和运行逻辑，所以它非常适合相当广泛的事件驱动开发场景。 事件的起始，要依靠触发器。 云上 Serverless 服务一般都配套提供了多种多样的触发器，包括 API 触发器、对象存储触发器、队列触发器等等。比如上面的实验中，我们用的就是API 触发器，它的触发条件为 API 网关带来的外部 Web 请求。 较为常用的还有对象存储触发器。比如当用户上传了一个文件，后台程序把它保存到对象存储中，这时相应的无服务器函数会被这个新对象触发，你就能对这个新上传的文件进行必要的处理了。 此外，还值得了解相当实用的定时触发器，它可以按照设置的条件周期性触发。通过它和云函数的配合，可以在一定程度上代替操作系统中 crontab 类工具起到的作用，也许能帮你节省一台专门触发运行定时任务的虚拟机。 如果说触发器是无服务器计算的上游的话，那么各种各样的外部交互方式，也让无服务器计算能够对外访问，并向下游输出。云端的 Serverless 环境中，一般都能够提供一系列重要类库和 SDK，让你能够在函数内访问其他云服务，尤其是像数据库、消息队列这样的外部存储。 所以，在云端…… 阅读全文

摘要：什么是应用托管服务 在云计算发展的早期，就已经出现了“建站类服务”，这正是应用托管服务的雏形。当时的建站类服务，会自动为你分配好服务器，安装好相应语言的 Web 环境以供你使用。在部署层面，服务通常会开放 FTP 端口，以便你上传服务器端的代码、脚本和资源。这是应用服务的一种轻量形式。 应用服务的本质就是为你的应用提供一个隔离的独立运行环境。作为用户来讲，你可以只专注于业务逻辑，不需要来手动创建这个环境，更不需要运维这个环境。 应用托管的增值服务 成熟的应用服务还能够提供许多增值服务，来进一步地满足我们在实际开发运维 Web 应用时，产生的各个层面的需求。 第一项增值服务就是监控 尤其是针对 Web 应用的特点而进行的 HTTP 层面的应用监控。所以，你不仅能看到计算资源的占用率，如 CPU、内存使用率等，还能看到许多应用层指标，比如总请求数、错误响应数、并发连接数、响应时间等等。这些都是你在监控应用运行时非常有帮助的信息，而这一切都是 PaaS 服务自动提供、开箱即用的功能。 而且，基于这些监控的指标，你还能够在云上制定相应的报警规则，当某些指标达到你设定的阈值时，会及时发送警报。这同样是一个非常实用的功能。 第二个方面是扩展 也就是底层计算资源和流量需求的匹配。这里既包含了底层机器配置的垂直扩展，也包含了机器数量层面的水平扩展。一旦你有调整需求，只需要动动手指发出指令，就可以随时升级相应的机器配置，并无缝切换。 特别是水平扩展的存在，它相当于同时包含了负载均衡和弹性伸缩，把它们都一股脑儿集成到了托管服务中。这意味着应用托管服务不是只能对应一台机器，而是能够创建多台机器来承接请求，并会在前端均衡地分发到多个实例上去。这里你同样可以指定自动伸缩的规则，来让应用服务自动地调整实例数量。 第三个方面是集成 这里是指与其他 PaaS 的集成。这是所有 PaaS 服务的优势，各个服务间可以互相帮助、联合作战，应用托管类服务也不例外。比如在监控数据方面，它可以和云监控系统进行衔接；再比如，有些云允许 Web 应用以目录的形式，挂载对象存储中的文件等等。 其中，应用托管类服务还有一项非常重要的集成能力，就是应用服务与云上 DevOps 组件和流程的无缝对接。它意味着应用服务可以作为整个应用生命周期管理的一部分，嵌入到持续集成的流程中去。借助和源代码管理设施的联动，你的应用…… 阅读全文

摘要：云上的关系型数据库 关系型数据库的应用在业界是最普遍的，也是云数据库首先进入的领域。这里的先行者同样是 AWS，早在 2009 年就发布了 RDS（Relational Database Service），后来其他的厂商也纷纷开始跟进。 云数据库在外部交互的层面上，保持了和传统“原版”数据库几乎完全一致的编程接口和使用体验。 比如说，你针对 MySQL 编写的 SQL 代码和应用层连接代码，包括你很熟悉和经常会使用的连接管理工具，除了要更改连接字符串和参数之外，都能够几乎不经修改地在云数据库的 MySQL 服务上运行。 另外，针对某个数据库的某个具体版本，云厂商们会把它的功能、内部机制完整地保留下来，以求获得最大程度的兼容性。早期比较简单的云数据库实现原理，是充分利用云上已经提供的虚拟机、云磁盘等 IaaS 层面的资源，在隔离的环境下进行数据库镜像的安装。而后来技术实力比较强大的厂商，还能够做到对数据库源码和模块的深度定制，在保证兼容性的前提下，进行许多对用户透明的云端适配和优化。 所以，云数据库尽管是一个受限的 PaaS 环境（比如它通常无法让你直接访问底层的服务器），但在使用体验上和传统数据库是相当一致的。你大可放心，之前积累的 MySQL 和 PostgreSQL 的知识，在 RDS 上也大都可以适用。在云上，你也同样能够找到和安装一些数据库的常用插件，来增强 PaaS 数据库的功能。 云数据库和传统数据库又很大的区别，这是指在搭建、运维、管理层面，云数据库提升了一个层次，实现了相当程度的智能化和自动化，极大地提升了用户友好度，降低了使用门槛。比如灵活的性能等级调整、详尽的监控体系、攻击防护机制等等，这些许多在传统数据库中需要借助额外工具或产品的功能，在云数据库服务是默认内置，可以开箱即用的。 除了这些基本能力外，还有两个最具代表性的云上关系型数据库的高级特性： 支持读写分离。当并发数量上升时，关系型数据库容易出现性能瓶颈。这时比较有用的办法，就是实现基于多库同步的读写分离。云数据库在产品后台略加操作，就可以启用这个功能：从创建从库到建立同步，再到读写流量分发，云数据库都能自动完成。 支持自动调优。对于数据库来说，同样和性能有关的一个重要工作，就是性能的调优。以前我们经常需要手动地观测性能瓶颈，找出热点查询，再考虑是否有改进性能的办法。而在现代云数据库中…… 阅读全文

摘要：对象存储，顾名思义，就是在云端，可以存放任意对象的存储服务。要注意这里的“对象”指的是任意的二进制对象，保存到云上通常是以二进制文件的形式，不要和“面向对象编程”中的对象混淆起来。 初识对象存储 通俗地解释起来，你可以这样理解，对象存储是你在云上可以创建的一种“网盘”。这个网盘可以存储任意的二进制文件，包括结构化和非结构化数据。你可以随时上传下载，也可以修改和删除。当然，云上对象存储会保证你数据的可靠性、可用性和扩展性，你不需要操心这些细节。 那么，同样是存储服务，对象存储和云硬盘有什么区别呢？ 第一个主要区别，在于访问的接口与形式。 云硬盘其实是挂载到虚拟机的虚拟硬盘，它是通过实现操作系统级别的底层接口，作为虚拟机的块存储设备而存在。我们也必须连接到相关的虚拟机，才能访问它里面的数据。 而对象存储，本质是一个网络化的服务，调用方主要通过高层的 API 和 SDK 来和它进行交互。不管是面向外部公开互联网服务，还是和内部应用程序对接，对象存储都是通过提供像 HTTP 这样的网络接口来实现的。所以它的独立性很强，不需要依赖其他组件就可以运作。 第二个主要区别，也是对象存储的一大特征，就是对象存储内本身不存在一个真正的文件系统，而是更接近一个键值（Key-Value）形式的存储服务。 这里的键就是对象的路径（路径中包含斜杠符号“/”），这里的值就是存储对象的二进制文件。 键值系统和云硬盘上经典文件系统的核心差异，就在于文件系统保存了更多的元数据，尤其是实现了目录结构和目录操作。而键值系统中，所谓的目录其实是多个对象共享的路径前缀，可以说是用前缀模拟出了目录。 第三个主要区别，在于对象存储的巨大容量。 作为云计算最具代表性的服务之一，它的可扩展性（Scalability）是毋庸置疑的，对象存储能够轻松地容纳上 PB 的超大容量数据，这是任何的云硬盘所不能企及的。所以对象存储是名副其实的大数据存储。 但从另一个角度说，对象存储和 HDFS 这样的大数据文件系统比起来，又有自己独到的优势：对象存储本身也是非常擅长和适合处理小文件的，即便是海量的小文件，对象存储也不会像 HDFS 那样处理起来捉襟见肘，可以说是“大小通吃”。 对象存储的高级特性 存储分层 在生产环境下的对象存储，我们往往会存放大量的文件和数据，这些文件的访问频率其实是会有很大差异的。比如说，对于一些比…… 阅读全文

摘要：什么是虚拟私有网络？ 虚拟私有网络（Virtual Private Cloud，简称 VPC），是云计算网络端最重要的概念之一，它是指构建在云上的、相互隔离的、用户可以自主控制的私有网络环境。虚拟私有网络有时也称为专有网络（阿里云）或虚拟网络（Virtual Network 或 VNet，Azure 的叫法）。 私有网络就是一张属于你自己的内网。内网之内的服务器和设备，可以比较自由地互相通信，与外界默认是隔离的。如果外部互联网，或者其他虚拟网络需要连接，则需要额外的配置。 所以说，虚拟私有网络，就是云上的保护网，能够有效地保护网内的各种设施。有的时候，可能还要同时创建多个虚拟网络，让它们各司其职，实现更精细的隔离。 虚拟私有网络麻雀虽小，但五脏俱全。在传统数据中心里，经典网络架构中的概念和组件，在虚拟网络中你几乎都能找到对应。这里比较重要的一些概念包括： 网段，私有网络的内部 IP 区段，通常用 CIDR 形式来表达，如 192.168.0.0/16。 子网，私有网络的下级网络结构，一个私有网络可以划分多个子网，这和通常意义上的子网也是对应和一致的。阿里云中把子网形象地称为“交换机”。 路由表，用于定义私有网络内流量的路由规则，决定着数据包的“下一跳”去向何方。每个子网都必须有一张关联的路由表，通常情况下，系统会自动帮你创建一个默认的路由表。 网关，是对进出私有网络的流量进行把守和分发的重要节点，根据用途的不同，有多种类型，后面我们还会讲到。 安全组，私有网络里虚拟机进出流量的通行或拦截规则，可以起到虚拟机网络防火墙的作用。 阿里云VPC体验 首先，来到阿里云的专有网络管理控制台，选择新建一个 VPC，这里的网段我们选择 192.168.0.0/16 。 注意：VPC 属于局域网，按照 RFC 规范，能够使用的 IPv4 区段必须为 192.168.0.0/16、172.16.0.0/12、10.0.0.0/8 这三个或它们的子集。 至少要创建一个子网，也就是交换机。 我们选择一个子 IP 段 192.168.0.0/24，并且设置所属可用区为“可用区 D” 我们再来创建另外一个交换机，网段设置为 192.168.1.0/24。这里的关键在于，我们可以让第二个交换机位于另外一个可用区 E。这就说明，我们可以建立跨可用区，也就是跨同区域内不同数据中心的私有网…… 阅读全文