enlyhua的专栏

【代码】1.1 架构师的自我修炼：技术 架构和未来(架构师的基础知识修炼) --- 操作系统原理：程序是如何运行和崩溃的。

第1章 DDD入门 即使软件中没有bug，也不能表示我们设计的软件模型本身就是好的。我们需要设计出能够准确表达业务意图的软件模型。 我能DDD吗？ 将领域专家引入团队是大有好处的。领域专家并不是一个职位，他可以是精通业务的人。 什么是领域模型？ 领域模型是关于某个特定业务领域的软件模型。通常，领域模型通过对象模型来实现，这些对象同时包含了数据和行为，并且表达了 准确的业务含义。 为什么我们需要DDD 1.领域专家和开发者一起工作，这样开发出来的软件能够准确的传达业务规则.

技术演示工程实践:

第16章　向微服务迈进16.1　目的：微服务的驱动力 硬件的成本能够持续的下降，而软件开发的成本则不可能。16.2　前提：微服务需要的条件 1.决策者与执行者都能意识到康威定律在软件设计中的关键作用 2.组织中具备一些对微服务有充分理解、有一定实践经验的技术专家 3.系统应具有以自治为目标的自动化与监控度量能力 4.复杂性已经成为制约生产力的主要矛盾16.3　边界：微服务的粒度 1.微服务粒度的下届是它至少满足独立---能够独立发布、独立部署、独立运行与独立测试，内聚---强相关的功.

第15章　服务网格 容器编排系统管理的最细粒度只能到达容器层次，在此粒度下的技术细节，仍然只能依赖程序员自己来管理，编排系统很难提供有效的支持。 服务网格： 是一种用于管理服务间通信的基础设施，职责是支持现代云原生应用网络请求在复杂拓扑环境中的可靠传递。在实践中，服务网格通常会 以轻量化网络代理的形式来体现，这些代理与应用程序代码部署在一起，对应用程序来说，它完全不会感知到代理的存在。 服务网格 只是一种处理程序间通信的基础设施，典型的存在形式是部署在应用旁边，一对一为应用提供服.

第14章　资源与调度 调度是指为新创建的pod找到一个最恰当的宿主机节点来运行它，这个过程成功与否，结果恰当与否，关键取决于容器编排系统是如何管理与分配集群节点的资源的。可以认为调度是必须以容器编排系统的资源管控为前提。14.1　资源模型 资源是什么，在k8s里面所有能接触的方方面面都被抽象成了资源，譬如表示工作负荷的资源(Pod,ReplicaSet,Service等)，表示存储的资源(Volume, PersistentVolume,Secret等)，表示策略的资源(SecurityCo.

第13章　持久化存储 容器是镜像的运行时实例，为了保证镜像能够重复的产出具备一致性的运行时实例，必须要求镜像本身是持久且稳定的，这决定了在容器中发生的一切数据变动操作都不能真正写入镜像当中，否则必然会破坏镜像不变的性质。为此，容器中的数据修改操作大多是基于写时复制(Copy-on-Write)策略来实现的。容器会利用叠加式文件系统(OverlayFS)的特性，在用户意图修改数据的时候，自动将变更的内容写入独立区域，再与原有的数据叠加到一起，使其从外观上看像是"覆盖"了原有内容。这种改动通常是临时的.

第12章　容器间网络 "虚拟化网络"是一项内容十分丰富，研究历史十分悠久的计算机技术，是计算机科学中一门独立的分支，完全不依附于虚拟化容器的存在。网络运营商提及的"网络功能虚拟化"(Network Function Virtualization,NFV)，网络设备商和网络管理软件提及的"软件定义网络"(Software Defined Networking,SDN)等都属于虚拟化网络的范畴。 下面讨论的是狭义的，它特指"如何基于Linux系统的网络虚拟化技术来实现容器间网络通信"，更通俗一点，.

第11章　虚拟化容器 容器的首要目标是让软件分发部署过程从传统的发布安装包、靠人工部署转变为直接发布意见部署好的、包含整套运行环境的虚拟化镜像。在容器技术成熟之前，主流的软件部署过程是由系统管理员编译或下载好二进制安装包，根据软件的部署说明文档准备好正确的操作系统、第三方库、配置文件、资源权限等各种前置依赖以后，才能将程序正确的运行起来。 一个计算机软件要能够正确运行，需要有以下三个方面的兼容性来保障： 1.ISA兼容 目标机器指令集的兼容性，譬如ARM架构的计算机无法直接运行面向x.

第10章　可观测性 客观测性，原本的含义是 "可以由其外部输出判断其内部状态的程度"。学术界一般会将可观测性分解为3个更具体的方向进行研究，分别是： 1.事件日志(Logging) 日志的职责是记录离散的事件，通过这些记录分析程序的行为，譬如曾经调用过哪些方法，操作过哪些数据库等。输出日志很容易，但收集和分析日志 可能会很复杂。 2.链路追踪(Tracing) 单体时代追踪的范畴基本只限于 栈追踪。微服务时代，追踪就不只局限于调用栈了，一个外部请求需要内部若干个服务的联动响应，.

第9章　可靠通信 微服务提倡 分散治理，不追求统一的技术平台。9.1　零信任网络 边界安全： 着重对经过网络区域边界的流量进行检查，对可信任区域(内网)内部的机器之间的流量则给与直接信任或者较为宽松的处理策略。 9.1.1　零信任安全模型的特征 零信任安全的中心思想是：不应当以某种固有特征来自动信任任何流量，除非明确得到了代表请求来源的身份凭证，否则一律不会有默认的信任关系。 传统网络安全模型与云原生时代零信任安全模型对比： 1.传统、边界安全模型 / 2.云原生、零信任模.

第8章　流量治理 容错性设计是微服务的另一个核心原则。随着拆分出的服务越来越多，随之而来会面临以下2个问题： 1.由于某一个服务崩溃，导致所有用到这个服务的其他服务都无法正常工作，一个点的错误经过层层传递，最终波及调用链上与此有关的所有服务，这便是 雪崩效应。如何防止雪崩效应便是微服务架构容错性设计的具体实践，否则服务化程度越高，整个系统反而越不稳定。 2.服务虽然没有崩溃，但由于处理能力有限，面临超过预期的突发的请求时，大部分请求直到超时都无法完成处理。类似于交通阻塞，如果一开始没有得到.

第7章　从类库到服务 在一套由多个微服务互相调用才能正常运作的分布式系统中，每个节点都互相扮演者服务的生产者与消费者的多重角色，形成了一套复杂的网状调用关系。此时，至少有(但不限于)以下三个问题是必须考虑并得到妥善解决的： 1.对消费者来说，外部的服务由谁提供？具体在什么网络位置？ 2.对生产者来说，内部哪些服务需要暴露？哪些需要隐藏？应当以何种形式暴露服务？以什么规则在集群中分配请求？ 3.对调用过程来说，如何保证每个远程服务都接收到相对平均的流量，获得尽可能高的服务质量与可靠性？ 这三个.

第6章　分布式共识 以同步为代表的数据复制方法,被称为状态转移,是比较符合人类的思维的可靠的保障手段,但通常要以牺牲可用性为代价. 可靠性与可用性的矛盾造成了增加机器数量反而带来可用性的降低。为了缓解这个矛盾，在分布式系统里主流的数据复制方法是以操作转移为基础的。我们想改变数据的状态，除了直接将目标状态赋予它之外，还有另外一种常见的方法是通过某种操作，令源状态换为目标状态。能够使确定的操作促使状态间产生确定的转移结果的计算模型，在计算机科学中称为状态机。 状态机的特性： 任何初始状态一.

第5章　架构安全性 计算机系统的安全，不仅仅是指"防御系统被黑客攻击"这样狭义的安全，还至少应包括以下问题的具体解决方案： 1.认证(Authentication) 系统如何正确分辨操作用户的真实身份。 2.授权(Authorization) 系统如何控制一个用户该看到什么数据，操作哪些功能？ 3.凭证(Credential) 系统如何保证它与用户之间的承诺是双方当时真实意图的体现，是准确的、完整且不可抵赖的。 4.保密(Confidentiality) 系统如何.

第4章　透明多级分流系统 对系统进行流量规划时，有2条简单、普适的原则能指导我们进行设计： a) 第一条原则是尽可能减少单点部件。如果某些单点是无可避免的，则应尽最大限度减少到达单点部件的流量。 b) 另外一条关键的原则是 奥卡姆剃刀原则。作为一名架构设计者，你应对多级分流的手段有全面的理解与充分的准备，同时清晰的意识到这些设施不是越多越好。在 实际构建系统时，你应当在有明确需求、真正必要的时候再去考虑部署它们。不是每一个系统都追求高并发、高可用的，根据系统的用户量、峰值流量和团队本身的技术.

第3章　事务处理 事务处理的意义在于，确保系统的所有数据都是符合预期的，且互相关联的数据之间不会产生矛盾，即数据状态的一致性(Consistency)。按照数据库的经典理论，要达成这个目标，需要三方面共同保证： 1.原子性(Atomic) 2.隔离性(Isolation) 3.持久性(Durability) 即数据库的ACID特性，AID是手段，C是目的，前者是因，后者是果。 事务的概念虽然起源于数据库，但今天已经有所延伸，不局限于数据库了。所有需要保证数据一致性的应用场景，包括但不限于.

第2章　访问远程服务 远程服务将计算机的工作范围从单机扩展至网络，从本地延伸至远程，是构建分布式系统的首要基础。2.1　远程服务调用 2.1.1　进程间通信 举例，一个正常的本地调用需要完成以下几个工作： 1.传递方法参数 2.确定方法版本 3.执行被调方法 4.返回执行结果 如果被调的方法不在本地进程。至少存在2个问题。首先，第一步和第四步所做的传递参数、传回参数都依赖于栈内存，如果Caller和Callee分属不同的进程， 就不会拥有相同的栈内存，此时将参数.

可靠的系统： 冯若依曼，自复制自动机理论： 这个理论一机器应该如何从基本的部件中构造出于自身相同的另一台机器引出，其目的不是想单纯的模拟或者理解生物体的自我复制，也不是想简单的制造自我复制的 计算机，而是想回答一个理论问题：如何用一些"不可靠"部件构造出一个可靠的系统。架构的演进： 从大型机(Mainframe)、原始分布式(Distributed)、大型单体(Monolithic)、面向服务(Service-Oriented)、微服务(Microservice)、服务网格(Service.

第17章 团队能力的提升 17.1 不确定性与风险把控 技术管理的首要任务是项目管理。对于项目管理，有一个关键问题要面对："不确定性"的问题。有哪些不确定性呢？ 1.需求的不确定性 2.技术的不确定性 3.人员的不确定性 4.组织的不确定性 5.历史遗留的问题17.2 以价值为中心的管理 技术的4层价值模型： 1.第一个层次 程序员最熟悉且经常谈论的：系统有多少个业务模块，功能多么强大，采用了多少新技术，采用了某个先进的算法。 2.第二个层次(非功能性需求.

第16章 个人素质的提升 16.1 能力模型 1.格局 举例说明什么是全局视野。比如现在要开发一个新系统，可能需要理解下面这些关系到"大局的问题"： 1.系统的定位是什么？它能创造什么核心价值？ 2.开发这个系统的背景是什么？为什么以前不做，现在要做？是因为业务发展到了一定规模？还是开发资源现在有多余的，没事可干？ 3.系统在整个组织架构中处于什么位置？与这个系统关联的其他系统目前处于什么状态？ 4.产品经理如何看待这个系统？技术负责人如何看待这个系统？ 5.这个系.

第15章 技术架构与业务架构的融合 15.1 各式各样的方法论 软件开发方法论： 1.OOA/OOD/OOP 分析模式与设计模式 面向对象的分析，设计与开发。 2.E-R建模 关系型数据库领域的建模方法论。 3.UML 在OOA/OOD基础上的一套成熟的建模方法和工具。 4.SOLID原则 在OOA/OOD基础上，敏捷开发提出的面向对象的几大原则。 5.SOA、微服务 基于服务的架构。 6.RUP 4+1 统一软件过程，架构的5大视图。.

第14章 业务架构思维 14.1 “伪”分层 典型的互联网分层架构： 客户端 => 接入层 => 聚合层 => 业务层 => 基础服务层 => 数据层 伪分层架构可能具有的一些特征： 1.底层调用上层 比如某个基础服务调用上层业务服务，怎么解决呢？ 办法1：要思考业务逻辑是否放错了地方？或者业务逻辑是否要一分为二，一部分放在业务服务，一部分放在基础服务。也就避免了底层调用上层。 办法2：OOD 中的典型办法，DIP(依赖反转)。底.

第13章 业务意识 13.1 产品经理vs.需求分析师 技术不是无源之水，一旦离开业务纯粹的谈技术，就失去了驱动技术发展的根本要素。另外一方面，研发部门的人力资源和时间是有限的，而业务需求是无限的，要用有限的资源应对无限的需求，必然存在需求取舍的问题，而这种取舍往往会有影响系统的架构设计。 具有良好的业务sense是做业务架构的基本条件，什么叫业务意识，这里抛出几个问题： 1.需求来自何处 如果是一个C端的互联网产品，需求可能来自 用户反馈或用户调研；如果是一个B端的产品，需求可.

第12章 CAP理论 12.1 CAP理论的误解 C：一致性。如事务一致性，多副本一致性。 A：可达性。客户端超时，也是不可达。 P：网络分区。系统一旦变成分布式，有多个节点，就可能存在超时或者网络中断。 在大规模分布式系统场景下，P(网络分区)往往是一个必然的存在，只能在C和A之间权衡。在实际中，大部分都是AP或CP的系统，而很少有CA的系统。CP的系统追求强一致性，比如zookeeper，但牺牲了一定的性能；AP的系统追求高可用，牺牲了一定的一致性，比如数据库的主从复制，kafka的主.

第11章 多副本一致性 无论是 mysql 的 master/slave，还是redis的 master/slave，或者是kafka 的多副本复制，都是通过牺牲一致性换取高性能的。 但如果需要一个既满足高可用，又满足一致性的系统，就需要一致性算法或者说一致性协议 --- Paxos,Raft,Zab。 工业界基于这些算法的工程实践有哪些： 1.Paxos 腾讯的 PhxPaxos,PhxSQL,PaxosStore; 阿里的 AliSQL X-Cluster,X-Paxos;.

第10章 事务一致性 一致性问题分为两类： 1.事务一致性 2.多副本一致性10.1 随处可见的分布式事务问题 分布式时代，数据库的单机机制不管用了，因为数据库本身只能保证单机事务，对于分布式事务，只能靠业务系统解决。10.2 分布式事务解决方案汇总 10.2.1 2PC 1.2PC理论 在讲mysql binlog 和 redo log 的一致性问题时，已经提到2pc。当然，那个场景只是内部的分布式事务问题，只涉及单机的两个日志文件之间的数据一致性； 2pc是.

第9章 高可用与稳定性 "高并发" 是为了让系统变得 "有效率"，高可用和稳定是是为了让系统变得 "更稳定"。9.1 多副本 对于网关和应用服务器这种无状态的服务，做多副本比较简单，加机器就行；但对于缓存和数据库这种有状态的，如果做多个副本，会存在数据同步问题。 1.本地缓存多副本 一种常用的方法是利用消息中间件(如kafka)的Pub/Sub机制，每台机器都订阅消息。一条消息发送出去，每台机器都会收到这台消息，然后更新自己的本地缓存。 2.Redis多副本 Redis Clu.

第8章 高并发问题 8.1 问题分类 8.1.1 侧重于“高并发读”的系统 1.场景一：搜索引擎 读写的差异： a) 数量级 b) 响应时间 c) 频率 2.场景二：电商的商品搜索 3.场景三：电商系统的商品描述，图片和价格 8.1.2 侧重于“高并发写”的系统 广告扣费系统： 1.用户每点击一次或浏览一次，都会对广告主的账号余额进行一次扣减； 2.这种扣减要实时，如果慢了，广告主的账户明明没钱了，但广告仍然在线播放，对平台造成损.

第7章 框架、软件与中间件 7.1 对生态体系的认知 技术的生态体系：就是从底层基础设施，到运维，中间件，大数据平台，这些技术之间可以很好的衔接，比如监控系统和rpc中间件，消息中间件，数据库的衔接，大数据平台和业务系统之间的衔接。从而让业务开发从技术问题中解脱出来，可以更好的服务业务。7.2 框架 做web开发，mvc 框架。如Java的 J2EE，SSH，Spring MVC，MyBatis，Python的Django，PHP的Zend，Ruby的 Ruby on Rails。7..

第6章 数据库 6.1 范式与反范式 数据库范式要求： 第一范式： 每个字段都是原子的，不能再分解。 第二范式： 1.表必有主键，主键可以是单个属性或者几个属性的组合。 2.非主属性必须完全依赖，而不能部分依赖。 第三范式： 没有传递依赖：非主属性必须直接依赖主键，而不能间接依赖主键。6.2 分库分表 6.2.1 为什么要分 1.分库的目的是要做"业务拆分"，通过业务拆分，把一个大的复杂的系统拆成多个业务子系统，之间通过RPC或者消息中间件通信。.

第5章 网络 5.1 HTTP 1.0 5.1.1 HTTP 1.0的问题 http协议的特点是"一来一回"。这样的协议有2个问题： 1.性能问题 2.服务端推送问题 5.1.2 Keep-Alive机制与Content-Length属性 为了解决第一个问题，http 1.0 设计了一个 Keep-Alive 机制来实现tcp连接的复用。具体来说，就是客户端在http请求的头部加上一个字段 Connection:Keep-Alive。服务端接收到这样字段的请求，在处理完.

第4章 操作系统 4.1 缓冲I/O和直接I/O 缓冲IO：缓冲IO是C语言提供的库函数，均以f打头； fopen,fclose,fseek,fflush,fread,fwrite,fprintf,fscanf; 直接IO：是Linux系统的API，操作系统的API也是C语言写的； open,close,lseek,fsync,read,write,pread,pwrite; 应用程序内存：是通常写代码用 malloc/free,new/delete 等分配出来的内存； 用户缓冲区.

第2部分 计算机功底第3章 语言 3.1 层出不穷的编程语言 3.2 精通一门语言

第2章 架构的道与术 2.1 何为道，何为术 这个方法论，即是架构的道。具体来说，对于技术问题，主要是指高并发，高可用和数据一致性方面；对于业务问题，主要是指 业务的需求分析和业务建模。 道比较虚，越是虚，越是抽象。术比较具体，具有实操性，容易描述。 2.2 道与术的辩证关系 知行合一。知，是理论，是套路，是解决问题的方法论；行，是实践，是操作，用于解决一个个实际问题。先有实践，然后总结出理论，用理论指导新的实践，在新的实践中 再总结出新的理论。...

第1部分 什么是架构 硬： 语言，数据结构与算法，操作系统原理，某种框架或中间件原理与使用方式。 软： 软件建模，架构设计等。 显性问题： 高并发，高可用，数据一致性问题。 隐形问题： 可重用性，可扩展性，可维护性等。 什么是架构？ 架构是针对所有重要问题作出的重要决策。不同公司或者同一家公司不同历史阶段面了的"重要问题"是不同的，所以架构所做的事情自然不同。第1章 五花八门的架构师职业 1.1 架构师职业分类 1.2 架构的分类 1.第一层：基础架构.

第9 章 网站高可用 网站可用性的提升，要同时从多方面入手，如软件架构设计实现，监控告警，紧急事件的响应，运维管理，容量管理，信息安全，灾备数据中心，故障演练等，这就是一个"反脆弱"的过程。 9．1 可用性指标与度量 "没有测量，就没有管理；没有测量，就没有改善"。 度量网站可用性的指标有很多，如下： 1.系统指标：以系统或硬件层面的监控数据来测量网站的可用性； 2.应用指标：如应用访问量，错误数，响应时长； 3.业务指标：如业务订单数，用户登录数，支付成功率等。.

第8 章 监控 8．1 指标监控和告警系统Hickwall Hickwall是xc在 Metrics 方面的主要监控系统，可以提供指标数据的采集，存储，展示和告警。 8．1．1 指标监控的应用和挑战 指标监控系统是一个对时序指标进行采集，分析和处理的系统，和日志系统不同的是，它并不记录时间或请求的详细信息，而是以数值的形式记录某个指标 随着时间的变化情况，这些数值被称为时间序列。 指标监控系统一般有以下几个应用场景： 1.容量规划 2.性能分析 3.紧急告警 .

第7 章 IaaS ＆ PaaS 如果想要产品交付越来越快，就需要提升基础设施的交付能力。虚拟化技术，通过OpenStack平台统一了虚拟机/物理机的资源交付，提供了真正意义上的IaaS服务。一套稳定的，可靠的，高效的持续交付平台---PaaS平台应用而生。在PaaS平台，我们从持续交付入手，打通了持续交付过程中核心的几个部分：资源，版本，发布。在版本方面，引入了git，包管理工具，依赖管理工具，静态代码扫描工具，对各种语言进行了标准化治理。同时，新打造的build平台，统一了编译，打包的标准和过.

第6 章 数据库 6．1 上传发布 数据库的上传发布，简而言之，就是DDL操作的过程，主要包括表的创建，表结构的调整，索引的调整等。 6．1．1 表结构设计规范 1.创建表的存储引擎必须是InnoDB：不能选择其他引擎 2.每张表必须有主键且不能使用联合主键：每行数据都能被唯一区分 3.默认使用utf8mb4字符集：uft8mb4字符集支持emoji表情符 4.每张表必须有modifytime字段：该字段定义为 " `modifytime` timestamp(3) not .