XIAOSUO 记录个人学习的足迹

摘要：云虚拟机到底是什么？ 云虚拟机，顾名思义，是在云端虚拟出的服务器。这个服务器你可以完全地控制它，从底层操作系统到安装上层应用。 站在技术实现的角度来讲，虚拟化技术是云虚拟机服务的核心，它本身是一个非常宏大的技术领域。比如你可能听说过 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的程序中，需要连接数据库，缓存甚至是队列等等。 一些大公司专门开发了自己…… 阅读全文

摘要：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…… 阅读全文