《微服务设计》--读书笔记

追求卓越的承诺：

1、仔细复查代码

微服务设计

《REST实战》

《企业集成模式》

蓝绿部署或金丝雀发布

版本管理

1、尽可能推迟

2、及早发现破坏性修改

3、使用语义化的版本管理

4、不同的接口共存

5、同时使用多个版本的服务

用户界面 组合层

是否能够很好地支持服务间的集成，用户界面是连接各个微服务的工具，只有把各个服务集成起来才能真正地为用户创造价值。

桌面端运行的胖客户端。Motif—— Swing。系统经常做的是创建和修改本地文件。

Web时代，让UI变得比较薄，把更多逻辑放在服务端。服务端程序渲染——基于浏览器的UI更多地采用JavaScript来添加懂改行为（有的变得跟老式桌面客户端一样臃肿）。

1、走向数字化 全局考虑 细粒度API，组合

2、约束 桌面Web 移动端 网络 操作 应对不同应用场景的约束

3、API组合 API 入口（gateway）多个底层的调用会被聚合成一个调用，有一定的局限性。

4、UI片段的组合 响应式组件

5、为前端服务的后端 BFF Backends For Frontends。

6、一种混合方式

与第三方软件集成

COTS产品：CMS和SaaS

1、缺乏控制 尽量把集成和定制化的工作放在自己能够控制的部分。

2、定制化 改变组织的工作方式

3、意大利面式的集成

4、在自己可控的平台进行定制化

CMS作为服务。动态内容，来源通常是组织内已经存在的其他服务。 管理内容的创 建和获取。

多职责的CRM系统，Customer Relationship Management，客户关系管理 项目

5、绞杀者模式 使用一系列的的微服务来实施拦截，捕获重定向这些原始调用复杂，需要代理来做这些事情。

第 5 章 分解单块系统

1、关键是接缝 《修改代码的艺术》

从接缝处可以抽取出相对独立的一部分代码，修改这部分不会影响其他部分。

识别出接缝——清理代码库——成为服务的边界

限界上下文——好的接缝——高内聚低耦合

编程语言——命名空间

2、分解MusicCorp

首先识别出组织中的高层限界上下文

单块系统能够被映射到哪些限界上下文中

产品目录、财务、仓库、推荐。

首先创建宝结构来表示这些上下文，然后把已有的代码移动到相应位置。IDE重构功 能来自动完成这些代码移动。需要测试来捕获任何可能的破坏性修改。

过段时间，剩下的代码——可能是遗漏的限界上下文。

structure101工具——可视化包之间的依赖。

3、分解单块系统的原因

增量的方式可以在进行过程中学习微服务，限制出错所造成的影响。

考虑把哪部分代码抽取出去得到的利益最大。

A、改变的速度，

B、团队结构

C、安全

D、技术

4、杂乱的依赖

备选的接缝，依赖关系，拉取出来的接缝应该尽量少地被其他组件所依赖。

接缝间可形成有向无环图，包建模工具可以提供帮助。

数据库说所有杂乱依赖的源头

5、数据库

6、找到问题的关键

代码中对数据库进行读写的部分，通常会存于一个仓储层中，其中会使用某种框架 Hibernate。

把仓储层的代码分成几部分。分离仓储层

数据库级别的约束，外键。需要工具可视化这些数据 SchemaSpy 使用图形的方式展现出表之间的关系。

7、打破外键关系

访问服务暴露的API来访问数据，而不是直接访问数据。

多次数据库调用，担忧性能。“慢”事实上还在可接受范围内。

放弃外键关联，需要实现跨服务的一致性检查，或者周期性触发清理数据的任务。

应该知道系统的期望行为是什么，然后再根据期望行为做决定。

8、共享静态数据

方法一，为每个包复制一份该表的内容，导致一致性问题。

方法二，静态数据放入代码，如属性文件或一个枚举。

方法三，静态数据放在一个单独的服务中。

大部分场景，都可以通过吧这些数据放入配置文件或者代码中来解决问题。易实现

9、共享数据

简单起见，所有信息都放在通用表中。需要分离。需要吧抽象的概念具象化，得到一个服务。

领域概念不是在代码中进行建模，相反是在数据库中隐式地进行建模。

10、共享表

分成两个表

11、重构数据库

分离数据库结构，《Refactoring DataBase》

实施分离，找到应用程序中的接缝，按照限界上下文对它们进行分组，且也找到了数据库中的接缝，尽量对其进行分离。推荐优先分离数据库结构，暂时不对服务进行分离。

逐步对服务进行分离

对数据访问次数可能会变多，分别从不同的地方拿到数据，然后在内存中进行连接。

分成两个表，会破坏事务完整性。

12、事务边界

事务是很有用的东西，保持一致性状态

跨越事务边界的单一操作

A、再试一次，要保证重试能够修复这个问题，最终一致性。对长时间的操作来说尤其管用。

B、终止整个操作，发起一个补偿事务来抵消之前的操作。难理解，不易实现。

C、分布式事务，横跨多个事务，然后使用一个叫作事务管理器的工具来统一编配其他底层系统中运行的事务。短事务，常用算法是两阶段提交，投票阶段。协调进程会使用锁。算法复杂且容易出错，尽量使用现有实现。

D、应该怎么办，分布式事务很容易出错，且不利于扩展。显示地创建一个概念来表示这个事务。如创建一个叫作“处理中的订单”的概念，围绕这个概念可以把所有与订单相关的端到端操作（及相应的异常）管理起来。

13、报告

搞清楚现有流程是如何工作的。选择好战场

14、报告数据库

报告系统会从副本数据库中读取数据。防止对主系统性能产生影响。

15、通过服务调用来获取数据

需要访问大数据量时，完全不适用了。

16、数据导出，

使用数据导出技术来周期性地把数据推送到报告数据库。

Cron触发一些命令程序就可以完成这个任务。

使用视图来构建一个单块报告程序的表结构。

17、事件数据导出

基于状态改变事件来将数据导出到报告数据库中。

事件流的时效特性。

低耦合及更好的数据时效性。

18、数据导出备份

Netflix，Cassandra，使用Hadoop，处理大量数据的流水线，且开源，Aegisthus项目

19、走向实时

能够包数据按需路由到多个不同地方的通用事件系统了。

20、修改的代价

强调做小的、增量修改的各种原因，能够理解做出的改变会造成什么影响。帮助我们更好地消除错误的代价。

在影响最小的地方犯错误。

在修改和犯错误的代价都很小的地方进行思考。也就是白板。把设计画在白板上。

一种在设计面向对象系统时的典型技术：CRC卡片，class-responsibility-collaboration，类-职责-交互。一张卡片，写上类的名字、它的职责及与谁进行交互。服务的职责列出来，写清楚它提供的了什么能力，和哪些服务之间有协作关系，遍历的用例越多，就越知道这些组件是否以正确的方式在一起工作。

21、理解根本原因

服务一定会慢慢变大，在事情变得太过昂贵之前，意识到需要做这个拆分。

找一个环境来做好配置并启动一个服务等任务并不简单。

应该尽量把它们变得简单。对库和轻量级服务框架的投资能够减少创建新服务的代价。

提供自助的虚拟机创建服务，或提供一个可用的PaaS，大大简化系统环境的创建及在此之上的测试工作。

 

第 6 章 部署

1、持续集成简介

CI，Continuous Integration，保证新提交的代码与已有代码进行集成，从而让所有人保持同步。

CI服务器会检测到代码已提交并签出，然后花时间来验证代码是否通过编译以及测试能否通过。

构建物，artifact，以供后续验证使用，如启动一个服务并对其运行测试。

能够得到关于代码质量的某种程度的快速反馈。自动生成二进制文件。所有代码都在版本的控制之下。可以从已部署的构建物回溯到相应的代码，运行过的测试可视化。

A、你真的在做CI吗？

这个关键实践允许我们更快速、更容易地修改代码。CI工具，CI实践。

三个问题：你是否每天签入代码到主线？你是否有一组测试来验证修改？当构建失败后，团队是否把修复CI当作第一优先级的事情来做？

2、把持续集成映射到微服务

把所有微服务放在同一个代码库中，并且只有一个CI构建。绝对应该避免这个模式，项目初期例外。

同步发布，lock-step release。

将一个代码库的子目录映射到不同的构建中。

每个微服务有一个源代码库和CI构建。跨服务做修改会更加困难，使用命令行脚本。

3、构建流水线和持续交付

把一个构建分成多个阶段时很有价值的。构建流水线。第一个阶段运行快速测试，第二个阶段运行耗时测试。

跟踪软件构建进度。流水线也能够可视化本次构建物的软件质量。

CD，Continuous Deliver，CD能够检查每次提交是否达到了部署到生产环境的要求，并持续的把这些信息反馈给我们，把每次提交当成候选发布版本来对待。

代码提交及部署到生产环境这个过程进行流程建模，并知道哪些版本的软件时可发布的。

编译及快速测试---耗时测试---用户验收测试---性能测试---生产环境

UAT，User Acceptance Tesing，用户验收测试。

对整个软件上线过程进行建模，软件质量的可视化得到了极大改善，大大减少发布之间的间隔。

不可避免的例外，项目启动，过渡阶段，花时间去了解领域。

4、平台特定的构建物

Ruby---gem，Java---JAR包和WAR包，Python---egg。

运行在Apache或Nginx中的进程管理器。

类似于Puppet和Chef、Ansible这样的自动化配置管理工具。

不同的技术栈生成的构建物各不相同。

5、操作系统构建物

RedHat或CentOS---RPM，Ubuntu--deb包，Windows---MSI

刚开始编写构建脚本的过程可能会比较困难。

6、定制化镜像

collectd收集操作系统的状态，使用logstash来做日志的聚合，nagios来做监控。

工具，自动化配置环境，脚本运行。

配置漂移。

创建虚拟机镜像，包含一些常用的依赖。节省时间。核心依赖没有改变。

构建镜像花费大量的时间，镜像可能会很大。容器技术。

Packer可以简化这个创建过程。

在生产环境使用AWS来做部署，并使用Vagrant镜像做本地开发和测试，它们都源于同一套配置。

A、将镜像作为构建物，

B、不可变服务器，机器修改，实际配置和源配置不再一致，配置漂移。

任何能够简化工作的措施都值得尝试。

7、环境

WebLogic的集群

重建类生产环境所消耗的时间和代价会让人望而却步，必须做出妥协。

类生产环境和快速反馈之间的平衡不是一成不变的。持续关注将来产生的Bug和反馈时间，按需去调节这个平衡。

8、服务配置

应该最小化环境间配置的差异。

使用专用系统来提供配置。

9、服务于主机之间的映射

主机（host），做通用的隔离单元。

注意：某些决定会限制可用的部署方式。

A、单主机多服务，简化开发人员的工作。使监控变得更加困难。服务的部署变得更复杂。限制部署构建物的选择。会增加对单个服务进行扩展的复杂性。

优化稀缺资源的利用。

按需计算平台、虚拟化技术的革新，使得内部基础设施的搭建更加灵活。

B、应用程序容器

节省语言运行时的开销。

不可避免地限制技术栈的选择。限制自动化和系统管理技术的选择。

强烈建议看看字包含的微服务构建物。Net，Nancy；Java，Jetty，自包含HTTP服务器。

C、每个主机一个服务

主机数量，如何降低管理大量主机带来的额外负担？

D、平台即服务

PaaS，Platform-as-a-Service，抽象层次高。依赖于特定技术的构建物，自动配置机器然后运行。

透明地对系统进行伸缩管理，允许控制服务的节点数量，平台处理其余的工作。

10、自动化

保持工作效率。资助式配置耽搁服务或一组服务的能力，大大简化开发人员的工作。

管理主机的工具。

应对复杂的微服务架构，自动化时必经之路。

两个案例研究：

11、从物理机及到虚拟机

管理大量主机的关键之一，找到一些方法把现成的物理机划分成小块。

基于容器的虚拟化（LXC）

A、传统的虚拟化技术

类型1虚拟化：只能运行在裸机上，不能运行在操作系统之上的技术。

类型2虚拟化：包含很多层，AWS、VMWare、VSphere、Xen和KVM。os，上运行hypervisor，对CPU和内存等资源作从虚拟主机到物理机的映射，提供一个控制虚拟机的层。

B、Vagrant

一个很有用的部署平台，在开发和测试环境时使用，而非生产环境。

在笔记本上创建一个虚拟云。底层使用标准的虚拟化系统（VirtualBox），可以使用文本文件来定义一系列虚拟机，且可在其中定义网络配置及镜像等信息。

快速反馈。

开发机会有很多额外的资源消耗。

C、Linux容器

创建一个隔离的进程空间，在这个空间中运行其他的进程。

每个容器就是整个系统进程树的一个子树。基本上所有现代Linux内核都提供LXC。

每个容器可以运行不同的操作系统发行版本，但必须共享相同的内核（因为进程树存在于内核中）。

启动非常快，几秒钟，更好地对容器进行资源分配，充分利用底层硬件。虚拟机，几分钟。

AWS的EC2，是一个能够提供短暂型按需计算的平台，与容器灵活运用。

外界请求路由到内部容器。

D、Docker

构建在轻量级容器之上的平台。处理了大多数与容器管理相关的事情。

在Vagrant中启动单个VM，在其中运行多个Docker实例，每个实例包含一个服务。

CoreOS一个专门为Docker设计的操作系统。经过裁剪的Linux OS。

只是一个在单机上运行的简单PaaS。需要一些工具，跨多台机器管理Docker实例上的服务。合适的调度层，Google的Kubernetes和CoreOS集成技术。

Deis，试图提供一个类似于Heroku的PaaS。

CaaS，Communications-as-a-Service，容器即服务。

快速启动和配置等。

12、一个部署接口

参数化的命令行调用是触发任何部署的最合理方式。CI工具来触发脚本的调用。

Windows批处理，bash，再到Python Fabric脚本。

部署的是什么，提供已知实体的名字，这里是微服务的名字，还需要实体的版本。部署到哪个环境中。

工具Fabric，一个被设计用来将命令行调用映射到函数的Python库，提供类似SSH的机制来控制缘层呢机器。结合Boto（AWS客户端）。

Windows使用PowerShell。

A、环境定义

微服务到计算、网络和存储资源之间的映射。

YAML文件进行描述，使用脚本从中获取数据。工作量很大，前期付出多。

Terraform（Hashicorp）

13、《持续交付》，对流水线设计和构建物管理

 

第 7 章 测试

自动测试

测试细粒度系统面临的问题与挑战。

《敏捷软件测试》

1、测试类型

顾问，使用各异的象限来对世界进行分类。

面向技术、面向业务、支持团队、评价产品

单于测试、非功能性测试、验收测试、探索性测试

尽可能多地使用自动化测试。快速有效的验证软件

2、测试范围

《Scrum敏捷软件开发》---测试金字塔模型 描述不同的自动化测试类型

思考不同的测试类型应该覆盖的范围，思考应该为这些不同的测试类型投入多大的比例。

单元测试、服务测试、用户界面测试（端到端测试）。

A、单元测试

通常只测试一个函数和方法调用。TDD，Test-Driven Design，测试驱动开发。

不启动服务，对外部文件和网络连接的使用也很限。

运行上千个测试，可能连一分钟都不需要。

帮助开发人员的。单元测试是彼此独立，分别覆盖一些小范围的代码。

对于功能是否正常快速给出反馈。对于代码重构非常重要。

B、服务测试

绕开用户界面、直接针对服务的测试。

只测试其中一个单独服务的功能。可以提高测试的隔离性，更快速地定位并解决问题。

给所有的外部合作者打桩，以便只把服务本身保留在测试范围内。

覆盖范围更大，更难定位问题。

C、端到端测试

覆盖整个系统。

通常需要打开一个浏览器来操作图形用户界面（GUI），容易模仿类似上传文件这样的用户交互。

D、权衡

选择不同的测试来覆盖不同的范围

E、比例

下层比上层多一个数量级。

反馈周期

测试反模式，测试甜筒或倒金字塔。

3、实现服务测试

部署服务的实例，给它的所有下游合作服务打桩

A、mock还是打桩

打桩，是指为被测试服务的请求创建一些有着预设响应的打桩服务。

mock还会进一步验证请求本身是否被正确调用。

过度使用mock会使测试变得脆弱。

用mock验证与其的副作用是否发生。

《测试驱动的面向对象软件开发》

B、智能的打桩服务

启动测试需要的打桩服务，Apache、Nginx、嵌入式Jetty，Python的Web服务器。

重复工作，ThoughtWorks Mountebank的打桩/mock服务器。

4、微妙的端到端测试

界面展示往往涉及多个服务。需要部署多个服务。比较慢，定位失败也更加困难。

让多个流水线扇入（fan in）到一个独立的端到端测试的阶段（stage）。任何一个服务的构建都会触发一次端到端测试。

5、端到端测试的缺点

6、脆弱的测试

服务数量越多，测试就会越脆弱，不确定性就越强。

异常正常化。应尽快找到这些脆弱的测试并消除它们。

发现立刻记录下来，不能立即修复时，先从测试套件中移除。

改变测试软件本身使之更容易测试也是一个正确的方向。

A、谁来写这些测试

编写测试，测试用例。

只要团队没有在第一时间测试自己所写的代码，就会出现很大的问题。

共享端到端测试套件的代码权，同时对测试套件联合负责。但实现服务的团队必须全都负责维护套件的健康。

B、测试多长时间

运行缓慢和脆弱性是很大的问题。切换大脑的上下文来修复测试是很痛苦。

并行运行测试可以改善缓慢的问题。Selenium Grid工具。

删除测试，困难的风险/回报权衡。更好地理解风险，这刚好是人类所不擅长的。

很少有人能够精细地对大范围、高负担的测试进行管理和维护。

希望它发生与真正让它发生是不一样的。

C、大量的堆积

反馈周期过长，影响开发人员的效率，修复失败周期变长。

端到端测试失败后，禁止提交代码。

部署的变更内容越多，发布的风险就会越高，就越有可能破坏一些功能。

保障频繁发布软件的关键：尽可能频繁地发布小范围的改变。

D、元版本

整个系统同一个版本号，糟糕---耦合

7、测试场景，而不是故事

把测试整个系统的重心放到少量核心的场景上来。

把任何在核心场景之外的功能放在相互隔离的服务测试中覆盖。

团队就核心场景达成一致，并共同拥有。

8、拯救消费者驱动测试

CDC，Consumer-Driven Contract，消费者驱动的契约。

只需针对生产者运行这些CDC测试，更快、更可靠。

生产者和消费者团队协作来写这部分测试。

A、Pact，一个消费者驱动的测试工具。

开源，Ruby语言----现支持JVM和NET版本。

消费者使用Ruby DSL来定义生产者的期望。然后启动一个本地mock服务器，并对其运行期望来生成Pact规范文件（标准的JSON）。提供一个mock服务器，可独立地测试消费。

B、关于沟通，

敏捷中，故事---一种促进沟通的方式。CDC也起到类似的作用。

9、还应该实用端到端测试吗

语义监控（semantic monitoring）的技术来监控生产系统，用到端到端场景测试。

生产环境中有效的监控和修复还是有必要的。

从生产环境中学习。

10、部署后再测试

A、区分部署和上线

在更多问题发生之前捕获它们。

针对新部署软件的一系列的冒烟测试套件。识别与环境有关的任何问题。

蓝绿部署，部署两份软件，但只有一个接受真正的请求。切换可以通过DNS条目或复杂均衡的配置。

保持旧版本运行，切换生产流量钱可以测试服务，大幅度减少发布软件所需的停机时间。生产机制重定向机制，甚至可以客户无感知进行版本切换，达到零宕机部署。

B、金丝雀发布 canary releasing

Web操作世界，平均故障间隔时间（Mean Time Between Failures，MTBF）和平均修复时间（Mean Time To Repair，MTTR）

尽快回滚加上良好的监控，类似蓝/绿部署

尽快发布软件，比构建健壮的软件更有意义，验证之前的想法或业务模型是否工作。

11、跨功能的测试

非功能性需求，系统展现的一些特性的一个总括的术语。

网页可接受的延迟时间，系统能够支持的用户数量，用户界面如何让残疾人也可访问，或如何保障客户数据的安全。

跨功能需求，Cross-Functional Requirement，CFR。系统性的仅仅是许多横切工作融合的结果。

很多CFR只能在生产环境测试，定义一些测试策略，归属性测试象限。

合适粒度的微服务会给你更多的机会做这些权衡。

负载测试，端到端，编写一个小范围的测试

强烈建议尽早去看CFR，并定期审查。

A、性能测试

追踪延迟的根源尤为重要。系统资源用于测试。

检查系统重的核心场景的性能。

模拟客户逐渐增多，在给定的客户场景一起运行。

运行时间长。每天运行一个子集，每周运行一个更大的集合。确保尽可能频繁地运行。

查看结果，人们不知道一个好的结果应该是什么样的。性能测试需要有目标。

变红的构建需要行动的一个清晰信号。

12、优化快速反馈，并相应地使用不同类型的测试。

尽可能使用消费者驱动的契约测试，来替换端到端测试。

使用消费者驱动的契约测试，提供团队之间的对话要点。

尝试理解投入更多的努力测试与更快地在生产环境问题发现之前的权衡（MTBF与MTTR权衡优化）

第 8 章 监控

单一故障点会极大地简化对问题的调查。

服务，集成更多的服务来完成功能。

多个服务需要监控，多个日志需要筛选，多个地方有可能因为网络延迟而出现问题。

监控小的服务，然后聚合起来看整体。最简单的系统---一个节点。

1、单一服务，单一服务器

监控主机本身，CPU、内存等。系统健康的时候呀它们应该是什么样子，当它们超出边界值时，就可以发出警告。

Nagios或New Relic这样的托管服务来帮助我们监控主机。

查看服务器本身的日志。logrotate帮助我们移除旧的日志，避免日志沾满磁盘空间。

监控应用程序本身，最低限度是要监控服务的响应时间。查看运行服务的Web服务器，或服务本身的日志。

追踪报告中错误出现的次数。

时间推移，负载增加，发现系统需要扩容。

2、单一服务，多个服务器

服务的多个副本实例，运行在多个独立的主机上。通过负载均衡分发不同的请求到不同的服务实例。

追踪有关主机的数据，根据他们来发出警告。

Nagios

几个主机，ssh-multiplexers工具，大屏显示，grep “Error” aap.log 定位错误。

响应时间，在负载均衡器中进行追踪。

健康的服务是什么样子的，当配置负载均衡器的时候，可以从应用程序中移除不健康的节点。

3、多个服务，多个服务器

从日志到应用程序指标，集中收和聚合尽可能多的数据到我们手上。

4、日志，日志，更多的日志

专门获取日志的子系统，让日志能够集中在一起方便使用。logstash，可以解析多种日志文件格式，并将它们发送给下游系统进行进一步调查。

Kibana，一个基于ElasticSearch查看日志的系统，查看聚合日志。查询语法搜索日志，可以把你发给它的日志生成图表。

5、多个服务的指标跟踪

收集系统指标足够长的时间，知道有清晰的模式浮现。

Graphite，提供一个非常简单的API，允许你实时发送指标数据给它。

了解趋势，帮助做容量规划。

在跟踪趋势和理解应该如何使用这些数据方面，使用方式越智能，我们的系统就越省钱，且响应性也就越好。

6、服务指标

Linux安装collectd并让它指向Graphite时，运行的操作系统会生成大量的指标

Nginx或Varnish这样的职场子系统，也会暴露很多有用的信息。

强烈建议公开自己服务的基本指标。Web服务，响应时间、错误率。

80%的软件功能从未使用过。

永远无法知道什么数据是有用的。

Codahale的Metrics库运行在JVM，允许存储一些指标，如计数器、计时器、计量表(gauge),将数据发送到Graphite和其他汇总报告系统提供现成的支持。

7、综合监控

定义正常的CPU级别，或者可以接受的响应时间，判断一个服务是否健康。

实现语义监控，非常小心地准备数据以满足测试的要求。确保不会触发意料之外的副作用。

8、关联标识

使用关联标识（ID），GUID。跟踪跨服务的调用。

Zipkin，Google自己的跟踪系统Dapper。

以标准化的方式处理它们。轻易地重建调用链。尤其是使用事件驱动的架构模式。

9、级联

监控系统之间的集成点非常关键

使用库实现一个断路器网络调用，优雅地处理级联故障和功能降级。JVM上的Hystrix。

10、标准化

以整的视角查看系统。标准化的方式记录日志。

工具在标准化方面可以提供帮助。提供预配置的虚拟机镜像，镜像内置logstash和collectd，还有一个公用的应用程序库，使得与Graphite之间的交互变得非常容易。

11、考虑受众

为不同的人收集这些数据。

现在需要知道什么？之后想要什么？图和消费数据。

定量信息的图形化显示。书籍《Information Dashboard Design：Displaying Data for AtaGlance Monitoring》

12、未来

Riemann是一个事件服务器，允许高级的聚合和事件路由。Suro是Netflix的数据流水线。

Storm的实时分析，离线批处理的Hadoop或日志分析的Kibana。

不再为不同类型的指标提供专门的工具链。而是提供伸缩性很好的更为通用的事件路由系统。提供灵活性，同时还能简化我们的架构。

13、对每个服务而言：

最低限度要跟踪请求响应时间。之后，可开始跟踪错误率及应用程序的指标。

最低限度要跟踪所有下游服务的健康状态，包括下游调用的响应时间，最好错误率。Hystrix。

标准化如何收集指标以及存储指标。

如果可能，以标准化的格式将日志记录到一个标准的位置。为简化聚合。

监控底层操作系统，可以跟踪流氓进程和进行容量规划。

对系统而言：

聚合CPU之类的主机层级的指标及应用程序级指标。

确保选用的指标存储工具可以在系统和服务级别做聚合，同事允许产看单台主机的情况。

确保指标存储工具允许维护数据足够长的时间，了解系统的趋势。

使用单个可查询工具来对日志进行聚合和存储。

强烈考虑标准化关联标识的使用。

了解什么样的情况需要行动，并根据这些信息构造相应的劲爆和仪表盘。

调查对各种指标聚合方式做统一化的可能性。像Suro或Riemannn

《Lightweight Systems for Realtime Monitoring》

 

第 9 章 安全

公司持有的用户信息的价值，以及保存在为客户构建的系统中的数据的价值。

数据传输，如何保护它们。底层操作系统和网络完全。

考虑人的因素。

1、身份验证和授权

身份验证，是确认他是谁的过程。用户的用户名和密码。主体（principal）

授权机制，可以把主体映射到他可以进行的操作中。

Django，框架提供了现成的用户管理功能。

分布式系统中，需要考虑更高级的方案。目的是要有一个单一的标识且只需进行一次验证。

A、常见的单点登录实现

B、单点登陆网关

每个服务，可以重定向到身份提供者，并与其进行握手。

网关作为代理。可以集中处理重定向用户的行为，且只在一个地方执行握手。

HTTP，信息翻到头上。Shibboleth工具。

带给你一种虚假的安全感。

深度防御，网络边界，到子网，防火墙，到主机，到操作系统，再到底层硬件。

C、细粒度的授权

使用粗粒度的角色，围绕组织的工作方式建模。

2、服务间的身份验证和授权

A、在边界内允许一切

被大所述组织采用。通信中使用HTTPS。

隐式信任模型并不是一个明智的决定。

B、HTTPS(S)基本身份验证

HTTP 头中发送用户名和密码，非常容易理解且得到广泛支持的协议。很高的风险。

HTTPS，客户端获取强有力的保证。服务端需要管理SSL证书。自签名证书

SSL之上的流量不能被反向代理服务器(Varnish或Squid)所缓存。

负载均衡中吧Https的请求转成Http的请求，然后在负载均衡后就可以使用缓存了。

C、使用SAML或OpenID Connect

D、客户端证书

TLS，Transport Layer Security，安全传输层协议。

每个客户端都安装一个X.509证书。证书管理的工作繁重。

D、HTTP之上的HMAC

Hash-based Message Authentication Code，基于哈希的消息码对请求进行签名，它是OAuth的一部分，并被广泛应用于亚马逊AWS的S3 API。

JWT，JSON Web Token,Json Web令牌

E、API秘钥

允许服务识别出谁在进行调用，然后对他们能做的进行限制。

更简单直接。

F、代理问题

安全漏洞，混淆代理人问题。

3、静态数据的安全

数据加密是一种责任。

A、使用众所周知的机密算法

AES-128或AES-256

关于密码，加盐密码哈希，salted password hashing。

B、一切皆与秘钥有关

C、选择你的目标

限制加密到一组指定的表是明智的做法。

D、按需解密

E、加密备份

清晰的秘钥管理变得非常重要。

4、深度防御

A、防火墙

ModSecurity是一种应用程序防火墙。

外围防火墙控制一般的访问，本地主机上使用IPTables，设置允许的入口和出口。

B、日志

C、入侵检测(预防)系统

IDS，Intrusion Detection System，可以监控网络或主机。

IPS，Intrusion Prevention System，入侵预防系统。

在可信范围内积极寻找可疑行为。

D、网络隔离

AWS自动创建VPN，Virtual Private Cloud，虚拟私有云，允许主机处在不同的子网中。

定义对等互连规则(peering rules)。

E、操作系统

给操作系统的用户尽量少的权限。

定期为你的软件打补丁。需要自动化。微软的SCCM，或红帽的Spacewalk

Anisble、Puppet或Chef工具

Linux，AppArmour，SeLinux，GrSSecurity。

5、一个示例

6、保持节俭

只存储完成业务运营或满足当地法律所需要的信息。

7、人的因素

社会工程学，站在恶意方的角度思考。内部信息。

8、黄金法则

使用众所周知的机密算法

9、内建安全

帮助培养开发人员的安全意识很关键，提高每个人对安全问题的普遍意识。

熟悉OWASP十大列表和OWASP安全测试框架。

安全专家

ZAP，Zed Attack Proxy

微软的安全开发周期。

10、外部验证

外部评估的价值很大。渗透测试。

团队并不总能看到自己所犯的错误。

信息安全团队。

11、小结

OWASP非盈利组织，Open Web Application Security Project,开放式Web应用程序安全项目。

开发人员必读物。

密码学 《Cryptography Engineering》

忽视人的因素会是一个严重的错误。

 

第 10 章 康威定律和系统设计

组织方面的问题。

行业年轻，不断地重塑自己。

摩尔定律。康威定律。

1968年4月，任何组织在设计一套系统(广义上的系统)时，所交付的设计方案在结构上都与该组织的沟通结构保持一致。

1、证据

A、松耦合组织和紧耦合组织

B、Windows Vista，容易出错。

2、Netflix和Amazon

Amazon，团队对他们所管理系统的整个生命周期负责的好处。小团队会比大团队的工作更有效。

“两个披萨团队”。

3、我们可以做什么

4、适应沟通途径

细粒度沟通，关于更改和重构的讨论更容易进行，且团队成员通常都很有责任感。

应分配单个服务的所有权给可以保持低成本变化的团队。

5、服务所有权

赋予团队更多的权利和自治，使其对工作更负责。

6、共享服务的原因

A、难以分割

考虑将团队合并在一起，以更紧密地匹配架构本身。

B、特性团队

服务根据业务领域建模，更容易保持对客户的关注。

C、交付瓶颈

标准化会导致团队降低采用正确的解决方案来解决问题的能力，并可能会降低效率。

7、内部开源

A、守护者的角色

核心团队，审批。花费大量精力与提交者进行清晰的沟通，并对他们的工作方式进行引导。

B、成熟

C、工具

pull分布式版本控制。需要支持讨论和修改提交申请的工具。

8、限界上下文和团队结构

9、孤儿服务

10、案例研究：RealEastate.com.au

交付服务团队，核心团队，提供建议、指导和工具。

系统架构并非凭空产生的。

11、反向的康威定律

12、人

如果没有把人们拉倒一条船上，想要的任何变化从一开始就注定会失败。

13、小结

组织规模化后的挑战

 

第 11 章 规模化微服务

1、故障无处不在

“分布式计算的故障”，网络是不可靠的。

尽力限制引起故障的因素。

拥抱故障。假设一切都会失败，从不同角度去思考如何解决问题。

2、多少是太多

跨功能需求，要考虑数据的持久性、服务的可用性、吞吐量和服务可接受的延迟等。

企业内网的知识库

可以容忍多少故障，或者系统需要多快，取决于系统的用户。反过来，帮助你了解哪些技术将对你有意义。

用户不是经常能阐明需求到底是什么，所以需要通过问题来提取正确的信息，并帮助他们了解提供不同级别服务的相对成本。

定义一些默认的跨功能需求，然后在特定的用例中重载他们。

响应时间/延迟、可用性、数据持久性

3、功能降级

弹性系统，

理解每个故障的影响，并弄清楚如何恰当地降级功能。

通过思考每项跨功能需求的重要性，对自己能做什么有更好的定位。

4、架构性安全措施

在系统中把它们标准化。

响应非常缓慢是最糟糕的故障模式之一。在分布式系统中，延迟是致命的。

HTTP链接池，正确地设置超时，实现舱壁隔离不同的连接池，并实现一个断路器，以便在第一时间避免给一个不健康的系统发送调用。

5、反脆弱的组织

《反脆弱》，事务实际上受益于失败和混乱。

游戏日，组织这类演练对于很多公司来说都是有益的。

Google，DiRT，Disaster Recovery Test，灾难恢复测试。

Netflix，在生产环境中通过编程引发故障。

混乱猴子(Chaos Monkey)，在一天的特定时间段随机停掉服务器或机器。

混乱大猩猩，延迟猴子

错误真正发生时，采用不指责文化。学习和演化过程的一部分。

开发人员被进一步授权，每个人都需要负责管理他的生产服务。

通过引发故障，并为其构建系统。

《Release It！》

A、超时 给所有的跨进程调用设置超时，并选择一个默认的超时时间。超时发生，记录到日志，并相应调整

B、断路器 如何实现，依赖于请求失败的定义，失败，快速失败，恢复，重置。Netflix Hystrix库。NET的Polly

C、舱壁 bulkhead 为下游服务的连接使用不同的连接池。关注点分离。最重要，减载---load shedding

D、隔离

6、幂等 多次执行所产生的影响，均与一次执行的影响相同。

7、扩展

A、更强大的主机 垂直扩展 非常昂贵

B、拆分负载

C、分散风险 虚拟机的根分区映射到单个SAN(Storage Area Network,存储区域网络)，大型且昂贵的。

SLA，Service-Level Agreement，服务等级协议。

将一个灾难恢复托管平台放到不同的供应商那里。

D、负载均衡 弹性 避免单点故障。大型昂贵的硬件设备，mod_proxy基于软件。

基于一些算法，将调用分发到一个或多个实例中。实例不健康---移除，恢复---添加进来

SSL终止 把所有服务实例都放在一个独立的VLAN里。

E、基于worker的系统

所有的实例工作在一些共享的待办作业列表上。改善作业的吞吐量、弹性

F、重新设计

新项目，快熟实验，了解需要构建哪些功能。

需要更改我们的系统来应对规模化，这不是失败的标志，而是成功的标志。

8、扩展数据库

A、服务的可用性和数据的持久性

B、扩展读取 缓存数据(性能显著) 只读副本 主从数据库 最终一致性 写主读从。

C、扩展写操作 分片 数据的关键字应用一个哈希函数，基于函数的结果决定将数据发送到哪个分片。

复杂性来源于查询处理，异步机制，结果放进缓存。Mongo使用Map/Reduce作业执行查询

Cassandra Riask

D、共享数据库基础设施 区分数据库本身和模式(schema)

E、CQRS Command-Query Responsibity Segregation，命令查询职责分离模式

9、缓存

是性能优化的一种方法。使用得当，带来巨大的性能好处。

HTTP，处理大量请求时，伸缩性良好的原因就是内置了缓存的概念。

对于分布式系统，缓存可以放在客户端或服务端

A、客户端、代理和服务器端缓存

代理，反向代理或CDN。

服务器端，Redis或Memcache，简单的内存缓存

B、HTTP缓存

C、为写使用缓存

D、为弹性使用缓存 定期去爬(crawl)现有的网站

E、隐藏源服务

F、保持简单

G、缓存中毒：一个警示

10、自动伸缩

新闻网站，混合使用预测型伸缩和响应型伸缩。

11、CAP理论

三方面权衡，一致性(consistency)、可用性(avaliability)、分区容忍性(partition tolerance)

最多保证三个中的两个

A、牺牲一致性

B、牺牲可用性

C、牺牲分区容忍性，CA系统在分布式系统中根本不存在

D、AP还是CP AP系统扩展更容易，且构建更简单，CP系统支持分布式一致性更多的挑战。了解操作的上下文

E、这不是全部或全不

F、真实世界

12、服务发现

A、DNS 处理不同环境中的服务实例，使用域名模板。DNS直接引用主机，将DNS条目解析到负载均衡器。

13、动态服务注册

A、Zookeeper

B、Consul 为服务发现提供一个HTTP接口，杀手锏提供了现成的DNS服务器。

指定的名字，提供一条SRV记录，其中包含IP和端口。内置节点健康检查。

高容错设计，以及在处理大量使用临时节点系统方面的专注。

把底层集群管理拆分出来，Serf处理节点检测、故障管理和报警。在其上添加了服务发现和配置管理

C、Eureka Netflix开源 在JVM进行标准化

D、构造你自己的系统 标签来帮助定义实例是做什么的，关联一些丰富的元数据到给定的主机。

E、别忘了人

14、文档服务

A、Swagger 为超媒体核心中的增量探索概念做的很少。

B、HAL和HAL浏览器 Hypertext Application Language，超文本应用程序语言。一个标准

描述公开的超媒体控制标准

15、自描述系统

SOAP早期，UDDI，Universal Description Discovery and Integration，通用描述、发现与集成服务。

简化信息的获取，是系统运行规模化管理复现出来的复杂性的关键工具。

16、小结

 

第 12 章 总结

1、微服务的原则

主要描述了该如何做，以及为什么应该这样做的问题。定义原则

协同工作的自治的小服务。整体使用的价值。

A、围绕业务概念建模 业务的限界上下文定义接口，比围绕技术概念定义的接口更加稳定。

也能更好的反映业务流程的变化。定义可能的领域边界

B、接受自动化文化 复杂性，管理大量的服务。

统一的命令行，以相同的方式把系统部署到各个环境是一个很有用的实践。

使用环境定义来明确不同环境间的差异。但同时使用统一的方式进行部署的能力。

创建自定义镜像来加快部署，创建全自动化不可变服务器，易定位系统本身的问题。

C、隐藏内部实现的细节

数据泵(data pump)或事件数据泵(event data pump),将跨多个服务的数据整合到一起，实现报表的功能。

尽量选择与技术无关的API。考虑使用REST，将内部和外部的视线细节分离方式规范化，即使是使用RPC，仍然可以采用这些想法。

D、让一切都去中心化

业务领域的专家。一些全局的引导是必要的，尝试使用共同治理模型，使团队的每个成员共同对系统技术愿景的演化负责。

企业服务总线或服务编配系统，会导致业务逻辑的中心化和哑服务，应避免使用它们。在服务限界内保持服务的内聚性。

E、可独立部署 消费者应该自己决定何时更新，你需要适应他们，

F、隔离失败

G、高度可观察 整体 注入合成事务，模拟真实用户的行为，使用语义监控查看系统是否运行正常。

聚合日志和数据 关联标识帮助跟踪系统间的调用。

2、什么时候你不应该使用微服务

越不了解一个领域，为服务找到合适的限界上下文就越难。

第一件事，花时间了解系统是做什么的，然后尝试识别出清晰的模块边界。

首先构建单块系统，当稳定后再进行拆分。

REA和Gilt

3、临别赠言

做决策，尽量缩小每个决策的影响范围

演进式架构，随时间的推移，逐步对系统进行一系列更改，保持系统的灵活性。

逐步前行，逐步学习

规则：持续地改变和演进系统

变化是无法避免的，所以，拥抱它吧。

20000种已知的蜂类中，只有7种被认为是蜜蜂。采食花粉和花蜜，并用蜂蜡建造蜂巢。蜂群内部分工明确。

花蜜中多糖酿造出蜂蜜。传播花粉