XIAOSUO 记录个人学习的足迹

摘要：什么是虚拟私有网络？ 虚拟私有网络（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。这就说明，我们可以建立跨可用区，也就是跨同区域内不同数据中心的私有网…… 阅读全文

摘要：云硬盘是什么？ 云硬盘，又叫做“云盘”或者“云磁盘”，就是云虚拟机上可以挂载和使用的硬盘。这里，它既包含了用于承载操作系统的系统盘，也包括了承载数据的数据盘。 在云计算的领域，有时，我们还会把云端磁盘服务叫做块存储（Block Storage），因为它们与 Linux 操作系统中的块设备相对应，是云上提供的“裸盘”，可以格式化并且施加文件系统。 既然是硬盘，那么它就与我们通常的认知相一致，当然是带有数据持久化功能的。这在专业上被称为“非易失性存储”（Non-ephemeral Storage），也就是说写入的数据不会丢失。即便所在虚拟机重启、关机甚至下线删除，这块云硬盘只要还存在，其中的数据也并不会被擦除。 事实上，云厂商对于云盘，不仅仅会保障数据的顺利写入，一般还会帮你在存储端同步和保留至少三份副本的数据。所以说，云硬盘的冗余度和可用性是非常之高的，一般极少发生云硬盘数据丢失的情况。 云硬盘与传统磁盘的真正差异在于，绝大多数的云硬盘都是远程的。我们都知道，在经典计算机的体系结构中，硬盘是通过本地机器内部主板的高速总线，与 CPU、内存等部件相连接；而在云端，你的硬盘则很可能并不在宿主机上，而是在专用的磁盘服务器阵列中，**两者是通过数据中心内部的特有 IO 线路进行连接。 ** 云硬盘的性能等级 第一个等级的云硬盘，是基于传统 HDD 硬盘构建而成的。这类云盘的性能一般，最高 IOPS 大概在数百左右。在很多的云上，已经不把它作为推荐的选择了。但它并非一无是处，成本低就是它的最大优势，在不注重性能的测试环境，或者是个人自用的服务器，它就是一个很好的选择。 第二个等级，往往是基于混合硬盘，也就是结合 HDD 和 SSD 硬盘构建的云硬盘。它会综合发挥 SSD 的性能优势和 HDD 的容量优势。比如它可以用 SSD 部分来承载热点区域数据，或是作为缓存，来提高响应性能。在这个等级下，典型的 IOPS 为数千左右，是很多云上创建硬盘的默认选项，比较适合像是操作系统启动盘这样的常规负载。 第三个等级的云硬盘，它的存储介质就是纯 SSD 硬盘了。虽然贵一些，但一分价钱一分货，这个等级下的云硬盘能够提供非常稳定的 IO 能力，IOPS 通常能够上万，也有相当不俗的吞吐量和较低的访问延时。你可以用它来承载生产环境中重要的关键业务应用，或是各类数据库等 IO 密集型应用。 …… 阅读全文

摘要：云虚拟机到底是什么？ 云虚拟机，顾名思义，是在云端虚拟出的服务器。这个服务器你可以完全地控制它，从底层操作系统到安装上层应用。 站在技术实现的角度来讲，虚拟化技术是云虚拟机服务的核心，它本身是一个非常宏大的技术领域。比如你可能听说过 Xen、KVM、VMWare、HyperV 等等虚拟化产品和技术。云计算中所使用的虚拟化技术，也大都是从这些虚拟化实现方式演化而来的。 云虚拟机的体系结构，用一句话来概括一下，就是全面解耦的计算存储分离的设计思想。 传统的虚拟化，往往是对单一物理机器资源的纵向切割，计算、存储、网络等各方面的能力都是一台物理机的子集。因此，从可伸缩性的角度来说，传统虚拟机存在较大的局限，当物理机的局部出现故障时，也很容易影响到里面的虚拟机。 得益于云端大规模的专属硬件以及高速的内部网络，云虚拟机的组成则有所不同。除了核心的 CPU 与内存部分仍属于一台宿主机外，它的网络、硬盘等其他部分，则可以超脱于宿主机之外，享受云端其他基础设施的能力。大致架构如下图所示： 这里我所给出的仅仅是一个简化加工之后的示意图。实际的云计算内部实现，会远比这个要复杂和精妙。不同的云的内部，也会有许多不同的专用硬件各显神通。 所以，云虚拟机，与其说是由一台宿主机虚拟而成的，不如说是云数据中心中的不同部分一起协，“拼凑”而成的一台机器。这样虚拟出来的机器，我们在使用感受上其实与传统服务器并无不同，但在可扩展性和故障隔离方面，它就具有很大的优势了。 云端“攒机”实战 第一步，当然是选择和确认虚拟机的所在区域。 随后，就是虚拟机的配置确认环节， 也就是我们通常所说的什么型号、几个核、几 G 内存的选择，配置的选择无疑非常重要。 接着，就有你需要注意的一个要点：选择操作系统镜像。 然后就是选择存储。 最后就是网络和安全组的配置 如何选择虚拟机型号 建立对虚拟机配置的多维认知 完整形容一个虚拟机的核心配置和能力，需要从多个角度来入手和描述。弄懂了这些重要维度的含义，你才能够准确理解一个虚拟机的性能预期和使用场景，从而作出正确的型号选择。这里并非只有决定 CPU 核数和内存大小这么简单。那么，主要是哪几个维度呢？ 第一个维度，就是虚拟机的“类型”，或者说“系列”。 一般来讲，云厂商会提供通用均衡型、计算密集型、内存优化型、图形计算型等常见的虚拟机类型。 通用均衡型的比例通常是 1…… 阅读全文

摘要：区域 云计算中最顶层的概念，就是区域（Region）了。在大家的日常认知中，它当然是一个地理概念。而在云计算行业中，区域对应的则是云计算厂商在某个地理位置提供的所有云服务的组合，是厂商对外提供云服务的基本单位和容器。 如何选择云上“区域”？ 首要的考量因素，当然在于区域的地理位置本身。 第二个考量因素，非常重要而又容易被忽视，那就是区域之间云服务的差别。 第三个区域选择的考量因素，则是成本因素。即便是同一种服务的价格，在不同区域也往往是不相同的。 多区域架构 多区域架构，它指的是部分关键应用，为了追求最佳的用户体验和高可用性，需要把多个区域的资源和能力结合起来进行构建。 在骨干网的加持下，通过合理架构完全可以让多个区域的云服务融为一体。**借助云的力量，小厂也能轻松拥有巨头的分布式部署能力。 ** 在应用架构层面，多区域并不意味着，我们需要把某区域的资源依葫芦画瓢复制到其他区域，而是可以**根据实际情况各司其职，让不同区域担任不同的角色，联动起来达到业务目的。 ** 比如，我们可以将面向消费者服务的触点部署到多个区域，就近服务各地区的互联网流量，而偏后台的数据分析和 BI 服务，则可以安置在性价比较高的非一线城市区域，业务数据可通过骨干网不断回传。这是一种经典的分工模式 。 当然，多区域架构固然诱人，我们也不应当走向另一个极端：轻率、随意地拓展区域。因为每一个区域的增加，都会相应增加应用架构的复杂性和流量费用，也给我们的维护工作带来负担，这些额外的成本可能会抵消多区域架构带来的好处。 可用区 除了“区域”之外，“可用区”（Availability Zone）这个术语同样是非常重要的概念。因为看上去和区域有点相似，经常会把它们等同看待。事实并非如此。 可用区是区域的下级概念，是指一个具备完整而独立的电力供应、冷却系统、网络设施的数据中心单元。一个区域通常由多个可用区高速互联组成。区域内的可用区一般位于同一个城市，之间相距往往在一百公里以内。 所以物理上的“数据中心”和“机房”概念，若要严谨地对应到云端，其实是在可用区这个层面。 那一个区域看上去拥有一个数据中心就足够了，为什么还要建造多个可用区呢？ 首要的原因，当然是为了解决区域内高可用性问题，这也正是“可用区”名字的由来。尽管数据中心内部有着非常精密的运作系统和冗余机制，但地震、火灾、雷击等极端情况下，仍有…… 阅读全文

摘要：需求背景 假设，你正在参与开发一个微服务。微服务通过 HTTP 协议暴露接口给其他系统调用，说直白点就是，其他系统通过 URL 来调用微服务的接口。有一天，你的 leader 找到你说，“为了保证接口调用的安全性，我们希望设计实现一个接口调用鉴权功能，只有经过认证之后的系统才能调用我们的接口，没有认证过的系统调用我们的接口会被拒绝。我希望由你来负责这个任务的开发，争取尽快上线。” 需求分析 1. 第一轮基础分析 对于如何做鉴权这样一个问题，最简单的解决方案就是，通过用户名加密码来做认证。我们给每个允许访问我们服务的调用方，派发一个应用名（或者叫应用 ID、AppID）和一个对应的密码（或者叫秘钥）。调用方每次进行接口请求的时候，都携带自己的 AppID 和密码。微服务在接收到接口调用请求之后，会解析出 AppID 和密码，跟存储在微服务端的 AppID 和密码进行比对。如果一致，说明认证成功，则允许接口调用请求；否则，就拒绝接口调用请求。 2. 第二轮分析优化 不过，这样的验证方式，每次都要明文传输密码。密码很容易被截获，是不安全的。那如果我们借助加密算法（比如 SHA），对密码进行加密之后，再传递到微服务端验证，是不是就可以了呢？实际上，这样也是不安全的，因为加密之后的密码及 AppID，照样可以被未认证系统（或者说黑客）截获，未认证系统可以携带这个加密之后的密码以及对应的 AppID，伪装成已认证系统来访问我们的接口。 这就是典型的“重放攻击” 。 提出问题，然后再解决问题，是一个非常好的迭代优化方法。对于这个问题，我们可以借助 OAuth 的验证思路来解决。调用方将请求接口的 URL 跟 AppID、密码拼接在一起，然后进行加密，生成一个 token。调用方在进行接口请求的的时候，将这个 token 及 AppID，随 URL 一块传递给微服务端。微服务端接收到这些数据之后，根据 AppID 从数据库中取出对应的密码，并通过同样的 token 生成算法，生成另外一个 token。用这个新生成的 token 跟调用方传递过来的 token 对比。如果一致，则允许接口调用请求；否则，就拒绝接口调用请求。 3. 第三轮分析优化 不过，这样的设计仍然存在重放攻击的风险，还是不够安全。每个 URL 拼接上 AppID、密码生成的 token 都是固定的。未认证系统截…… 阅读全文

摘要： 中央处理器（CPU），是电子计算机的主要设备之一，电脑中的核心配件。其功能主要是解释计算机指令以及处理计算机软件中的数据。CPU是计算机中负责读取指令，对指令译码并执行指令的核心部件。中央处理器主要包括两个部分，即控制器、运算器，其中还包括高速缓冲存储器及实现它们之间联系的数据、控制的总线。电子计算机三大核心部件就是CPU、内部存储器、输入/输出设备。中央处理器的功效主要为处理指令、执行操作、控制时间、处理数据。 [2] 在计算机体系结构中，CPU 是对计算机的所有硬件资源（如存储器、输入输出单元） 进行控制调配、执行通用运算的核心硬件单元。CPU 是计算机的运算和控制核心。计算机系统中所有软件层的操作，最终都将通过指令集映射为CPU的操作。 在计算机体系结构中，CPU 是对计算机的所有硬件资源（如存储器、输入输出单元） 进行控制调配、执行通用运算的核心硬件单元。CPU 是计算机的运算和控制核心。计算机系统中所有软件层的操作，最终都将通过指令集映射为CPU的操作。 阅读全文

摘要：前言 微服务已经成为目前开发的主流设计，我们也要与时俱进不能一直还停留在三层架构的思想层面。年前也更大家简单介绍过什么是微服务，以及实现微服务中需要用到的一些相关技术。之前一直停留在工具和代码阶段，那具体应该如何设计如何落地呢？微服务设计过程中往往会面临边界如何划定的问题，微服务到底应该拆多小，不同的人会根据自己对微服务的理解而拆分出不同的微服务，如何我们还是不经过设计，只是靠拍脑袋硬完成开发的话，上线后运维的压力将会远大于单体程序。那是否有合适的理论或设计方法来指导微服务设计呢？答案就是DDD。微服务拆分困境产生的根本原因就是不知道业务或者微服务的边界到底在什么地方。换句话说，确定了业务边界和应用边界，这个困境也就迎刃而解了. 2004 年埃里克·埃文斯（Eric Evans）发表了《领域驱动设计》（Domain-Driven Design –Tackling Complexity in the Heart of Software）这本书，从此领域驱动设计（Domain Driven Design，简称 DDD）诞生。DDD 核心思想是通过领域驱动设计方法定义领域模型，从而确定业务和应用边界，保证业务模型与代码模型的一致性。但 DDD 提出后在软件开发领域一直都是“雷声大，雨点小”！直到 Martin Fowler 提出微服务架构，DDD 才真正迎来了自己的时代。利用 DDD 设计方法来建立领域模型，划分领域边界，再根据这些领域边界从业务视角来划分微服务边界。而按照 DDD 方法设计出的微服务的业务和应用边界都非常合理，可以很好地实现微服务内部和外部的“高内聚、低耦合”。于是越来越多的人开始把 DDD 作为微服务设计的指导思想。现在，很多大型互联网企业已经将 DDD 设计方法作为微服务的主流设计方法了。DDD 也从过去“雷声大，雨点小”，开始真正火爆起来。 DDD知识体系 领域 领域不断划分的过程中，领域会细分为不同的子域，子域可以根据自身重要性和功能属性划分为三类子域，它们分别是：核心域、通用域和支撑域。 核心域：系统最核心并有复杂业务逻辑的业务界限上下文，比如OA系统的物资管理。 支撑域：系统支撑其他界限上下文的基础，比如OA系统的员工基础资料。 通用域：需要使用的基础框架或第三方成熟解决方案，比如OA系统工作流引擎。 工作流引擎是个比较大的领域，目前我们…… 阅读全文

摘要：1. 目标 如下代码：我们要实现缓存，但希望让使用者不用关心缓存的具体实现，只需要使用者在要操作缓存的方法上加上特性标注即可。 [Caching(CachingMethod.Remove, GetLinksQuery)] public class CreateLinkCommand {     } ​ [Caching(CachingMethod.Get)] public class GetLinksQuery : IRequestListLinkViewModel {     } 要实现我们的目标，我们把任务分成2部分，首先实现缓存逻辑，然后将缓存基于特性做AOP实现。 2. 缓存实现 首先我们定义一个缓存接口 public interface ICacheProvider {    /// summary    /// 向缓存中添加一个对象。    /// /summary    /// param name=key缓存的键值，该值通常是使用缓存机制的方法的名称。/param    /// param name=valKey缓存值的键值，该值通常是由使用缓存机制的方法的参数值所产生。/param    /// param name=value需要缓存的对象。/param    void Add(string key, string valKey, object value);    void Put(string key, string valKey, object value);    object Get(string key, string valKey);    void Remove(string key);    bool Exists(string key);    bool Exists(string key, string valKey); } 如上代码，为什么接口中key和valKey2个参数呢？这是因为我们可能会缓存同一个方法不同参数的结果，如在一个获取分页结果的方法中，我们可能会返回不同页的结果。如我们目标中GetLinksQuery方法缓存的值会是一个分页显示结果的字典。key是我们缓存的方法名，valKey这是缓存的字典结果中的字典key，value则是字典的结果。要进一步理解可以查看下面基于内存的…… 阅读全文

摘要：#本方案定义公司实施微服务的开发标准，规定了源码的分层结构、各层次的编码规范；单个微服务采用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…… 阅读全文

摘要：Deployment 使用 Kubernetes提供了一种更加简单的更新RC和Pod的机制，叫做Deployment。通过在Deployment中描述你所期望的集群状态，Deployment Controller会将现在的集群状态在一个可控的速度下逐步更新成你所期望的集群状态。Deployment主要职责同样是为了保证pod的数量和健康，90%的功能与Replication Controller完全一样，可以看做新一代的Replication Controller。但是，它又具备了Replication Controller之外的新特性：Replication Controller全部功能：Deployment继承了上面描述的Replication Controller全部功能。 事件和状态查看：可以查看Deployment的升级详细进度和状态。 回滚：当升级pod镜像或者相关参数的时候发现问题，可以使用回滚操作回滚到上一个稳定的版本或者指定的版本。 版本记录: 每一次对Deployment的操作，都能保存下来，给予后续可能的回滚使用。 暂停和启动：对于每一次升级，都能够随时暂停和启动。 多种升级方案：Recreate----删除所有已存在的pod,重新创建新的; RollingUpdate----滚动升级，逐步替换的策略，同时滚动升级时，支持更多的附加参数，例如设置最大不可用pod数量，最小升级间隔时间等等。 #创建命令：kubectl create -f deployment.yaml --record #使用rollout history命令，查看Deployment的历史信息：kubectl rollout history deployment cango-demo #使用rollout undo回滚到上一版本: kubectl rollout undo deployment cango-demo #使用–to-revision可以回滚到指定版本: kubectl rollout undo deployment hello-deployment --to-revision=2 1234 ConfigMap 配置 在几乎所有的应用开发中，都会涉及到配置文件的变更，比如说在web的程序中，需要连接数据库，缓存甚至是队列等等。 一些大公司专门开发了自己…… 阅读全文