O'Reilly出版《微服务设计》阅读整理

《微服务设计》原版是O'Reilly Media, Inc在2015年出版，英文原版书名《Building Microservices》。
简体中文版由人民邮电出版社出版。我读的是简体中文版。

-------------------------------------------------------------------------
以下是我本人的书评
本书是2016年出版的，英文版是2015年出版的，微服务算是比较新的一项技术（或思想）。本书以宏观的角度讲述了微服务的理论思想，从下面的目录架构也能看出来，作者在第2章用了一章的篇幅讲了微服务中的架构师角色。什么是微服务? 微服务如何寻找平衡? 如何测试？等等，这些问题作者在书中都作了解答。
书的广度很广，介绍了很多工具、架构以及书，深度就需要自己再探索。虽说是介绍微服务的，但很多思想对于分布式架构也能适用。总而言之，很是本扩展知识面的难得的好书~
-------------------------------------------------------------------------

前言

微服务是一种分布式系统解决方案，推动细粒度服务的使用，这些服务协同工作，且每个服务都有自己的生命周期。（归纳起来就是小而自治的服务）。

作者对本书结构的介绍（目录）:

• 第1章，微服务: 首先介绍微信服的基本概念，包括微服务的主要优点以及一些缺点。
• 第2章，演化式架构师: 这一章讨论了架构师城要做出的权衡，以及在微服务架构下具体有哪些方面是我们需要考虑的。
• 第3章，如何建模服务: 在这一章我们使用领域驱动设计来定义微服务的边界。
• 第4章，集成: 这一章开始深入具体的技术，讨论什么样的服务集成技术对我们帮助最大。我们还将深入研究用户界面，以及如何集成遗留产品和COTS（Commercial Off-The-Shelf，现成的商业软件）产品这个主题。
• 第5章，分解单块系统: 很多人对于如何把一个大的、难以变化的单块系统分解成微服务很感兴趣，而这正是我们将在这一章详细介绍的内容。
• 第6章，部署: 尽管这本书讲述的主要是微服务的理论，但书中的几个主题还是会受到最新技术的影响，部署就是其中之一，我们在这一章会探讨这方面的内容。
• 第7章，测试: 本章会深入测试这个主题，测试在部署多个分散的服务时很重要。特别需要注意的是，消费者驱动的契约测试在确保软件质量方面能够起到什么样的作用。
• 第8章，监控: 在部署到生产环境之前的测试并不能完全保证我们上线后没有问题。这一章探讨了细粒度的系统该如何监控，以及如何应对分布式系统的复杂性。
• 第9章，安全: 这一章将会研究微服务的安全，考虑如何处理用户对服务及服务间的身份验证和授权。在计算领域，安全是一个非常重要的话题，而且很容易被忽略。尽管我不是安全专家，但我希望这一章至少能帮助你了解在构建系统，龙其是微服务系统时，需要考虑的一些内容。
• 第10章，康威定律和系统设计: 这一章的重点是组织结构和系统设计的相互作用。许多组织已经意识到，两者不匹配会导致很多问题。我们将试图弄清楚这一困境的真相，并考虑一些不同的方法将系统设计与你的团队结构相匹配。
• 第11章，规模化微服务: 这一章我们将开始了解规模化微服务所面临的问题，以便处理在有大量服务时失败概率增大及流量过载的问题。
• 第12章，总结: 最后一章试图分析微服务与其它架构有什么本质上的不同。我列出了微服务的七个原则，并总结了本书的要点。

-------------------------------------------------------------------------
以下是摘录:

【第1章】微服务
微服务的特性: 内聚性、自治性。

对于一个服务来说，我们需要考虑的是什么应该暴露，什么应该隐藏。有一个黄金法则是: 你是否能够修改一个服务并对其进行部署，而不需响其他任何服务？为了达到解耦的目的，你需要正确地建模服务和API。

对于部署来说，两次发布之间的差异越大，出错的可能性就更大。（开发都深有体会的事~）

【第2章】演化式架构师
架构师的一个重要职责是，确保团队有共同的技术愿景，以帮助我们向客户交付他们想要的系统。

更准确的来说，架构师可以类似城市规划师，而不是建筑师。

作为架构师，不应该过多关注每个区域内发生的事情，而应该多关注区域之间的事情。

规则对于智者来说是指导，对于愚蠢者来说是遵从。

如果你所在的组织对开发人员有非常多的限制，那么微服务可能并不适合你。

我坚定的相信，伟大的软件来自于伟大的人。所以如果你只担心技术问题，那么恐怕你看到的问题远远不及一半。

【第3章】如何建模服务
什么样的服务是好服务: 松耦合和高内聚。

当你在思考组织内的限界上下文时，不应该从共享数据的角度来考虑，而应该从这些上下文能够提供的功能来考虑。所以首先要问自已“这个上下文是做什么用的”，然后再考虑“它需要什么样的数据”。

【第4章】集成
REST是RPC的一种替代方案。（RPC: Remote Procedure Call，REST: Representational State Transfer。）

开发人员对DRY这个缩写非常熟悉，即Don't Repeat Yourself。

客户端尽可能灵活地消费服务响应这一点符合Postel法则（也叫作鲁棒性原则，https://tools.ietf.org/html/rfc761）。该法则认为系统中的每个模块都应该“宽进严出”，即对自己发送的东西要严格，对接收的东西则要宽容。这个原则最初的上下文是网络设备之间的交互，因为在这个场景中，所有奇怪的事情都可能发生。在请求/响应的场景中，该原则可以帮助我们在服务发生改变时，减少消费方的修改。

【第6章】部署
持续集成（CI）: 1）你是否每天签入代码到主线？2）你是否有一组测试来验证修改？3）当构建失败后，团队是否把修复CI当作第一优先级的事情来做？

微服务集成推荐: 每个微服务都有自己的CI。

持续交付（CD）

使用构建流水线建模的标准发布流程:
线译及快速测试--> 耗时测试-->用户验收测试--> 性能测试--> 生产环境

UAT: User Acceptance Testing，用户验收测试。

应用程序容器推荐模式: 每个主机一个服务。

平台即服务（PaaS: Platform-as-a-service）: Heroku: 能够管理服务的运行，还能以非常简单的方式提供数据库等服务。

下图: 标准类型2虚拟化和轻量级容器技术的对比:


类型2虚拟化: AWS,VMWare（这个相信很多人用过）, VSphere等。
Linux容器: 思想/或是举个例子: 如果在终端启动了一个进程，你可以认为它是终端程序的子进程。Linux内核的任务就是维护这个进程树。每个容器就是整个系统进程树的一棵子树。

Docker是构建在轻量级容器之上的平台。

未来的发展趋势: 容器即服务: Caas（Communications-as-a-Service）。

【第7章】测试
测试分类体系:


流程: 构建--> 单元测试--> 服务测试--> 【端到端的测试】

金丝雀发布（canary releasing）: 指通过将部分生产流量引流到新部署的系统，来验证系统是否按预期执行。

平均故障间隔时间和平均修复时间。

【第8章】监控
监控小的服务，然后聚合起来看整体。

如果我们想运行自己的监控软件，可以使用Nagios，或是使用像New Relic这样的托管服务来帮助我们监控主机。

一个服务，多个主机: 使用ssh -multiplexers工具来解析。

多个服务，多个主机:

• logstash（http://logstash.net），可以解析多种日志文件格式，并将它们发送给下游系统进行进一步调查。
• Kibana（http://www.elastic.co/products/kibana）是一个基于ElasticSearch查看日志的系统。

Graphite：提供简单的API，允许实时发送指标数据给它，然后生成指标（如平均的CPU负载）的图表。

推荐使用关联标识来跟踪跨多个服务的调用。


【第9章】安全
通常来说，当我们抽象地讨论进行身份验证的人或事时，我们称之为主体（principal）。

单点登陆（人与服务间的验证）:


服务间的身份验证: HTTP(S)基本身份验证（SSL证书）、使用SAML或OpenId Connect、客户端证书、HTTP之上的HMAC、API密钥。

加密:
对于静态数据的加密，除非你有一个很好的理由选择别的，否则选择你的开发平台上的AES-128或AES-256的一个广为人知的实现即可。（无论哪种语言，这些加密算法都是经过同行评审，并定期打补丁的。）

关于密码，可以考虑使用一种叫加盐密码哈希（salted password hashing, https://crackstation.net/hashing-security.htm#properhashing）

密钥:
加密的过程依赖一个数据加密的算法和一个密钥，然后使用二者对数据进行加密。关于密钥的存放，一个解决方案是: 使用单独的安全设计来加密和解密数据。

操作系统: 如果你正在使用Linux操作系统，可以看看操作系统本身安全模块的发展。如AppArmour允许你自定义应用的预期行为，内核会对其进行监控。如果它开始做一些不该做的事情时，内核就会介入。（Ubuntu\SuSE默认使用AppArmour，而RedHat支持的是SELinux）。

更安全的系统示例:


本章的黄金法则: 不要实现自己的加密算法，不要发明自己的安全协议。除非你是一个有多年经验的密码专家。

【第10章】康威定律和系统设计
我们的行业还很年轻，一些关键定律还是经受住了时间的考验。如摩尔定律（它表示集成电路上可容纳的晶体管数目每两年会增加一倍。）还有一条定律，就是康威定律。

梅尔.康威于1968年4月在Datamation杂志上发表了一篇名为“How Do Committees Invent”的论文中指出: 任何组织在设计一套系统（广义概念上的系统）时，所交付的设计方案在结构上都与该组织的沟通结构保持一致。

更详细点的解释: 埃里克.S.雷蒙德在《新黑客字典》中总结这一现象时指出: 如果你有四个小组开发一个编译器，那你会得到一个四步编译器。

松耦合组织（如分布式开源社区）和紧耦合组织（如商业产品公司），研究表明，通过匹配不同类型的组织中比较相似的产品中，发同组织的耦合度越低，其创建的系统的模块化就越好，耦合也越低；组织的耦合度越高，其创建的系统的模块化就越差。

【第11章】规模化微服务
规模化后，即使你买最好的工具，最昂贵的硬件，也无法避免它们会发生故障的事实。

在分布式架构下，准备好如何应对各种故障是非常重要的，具体如下:
超时、断路器、舱壁、隔离、幂等、扩展

负载均衡（Load balance）:


另外，像mod_proxy这样的软件，可以发挥类似软件负载均衡器的作用。

扩展写操作: 使用分片。如Mongo。
Cassandra在不停机的情况下添加额外的分片这方面就处理很好。

缓存: 是性能优化常用的一种方法。
HTTP缓存: cache-control指令，Expires头部，Etag等
服务器缓存

CAP定理: 在分布式系统中有三方面需要彼此权衡: 一致性（consistency）、可用性（availability）和分区容忍性（partition tolerance）。具体地说，这个定理告诉我们最多只能保证三个中的两个。

ZooKeeper（http://zookeeper.apache.org）最初是作为Hadoop项目的一部分进行开发的。它被用于令人眼花缭乱的众多使用场景中，包括配置管理、服务间的数据同步、leader选举、消息队列和命名服务等。

Consul（http://www.consul.io）也支持配置管理和服务发现。

Swagger让你描述API，产生一个很友好的Web用户界面，使你可以查看文档并通过Web浏览器与API交互。

超文本应用程序语言: HAL（Hypertext Application Language.）

【第12章】总结
微服务（自治的小服务），列出一些原则:

• 围绕业务概念建模
• 自动化的文件
• 隐藏内部实现细节
• 一切都去中心化
• 独立部署
• 隔离失败
• 高度可观察

-------------------------------------------------------------------------
书中提及的其它书籍、理论、技术:

Eric Evans《领域驱动设计》: 帮助我们理解了用代码呈现真实世界的重要性，并且告诉我们如何更好的进行建设。

Alistair Cockburn《六边型架构理论》: 把我们从分层架构中拯救出来，从而能够更好地体现业务逻辑。
http://alistair.cockburn.us/Hexagonal+architecture

Robert C. Martin单一职责原则（Single Responsibility Principle）: 把因相同原因而变化的东西聚合到一起，而把不同原因而变化的东西分离开来。

SOA（Service-Oriented Architecture）: 面向服务的架构。
OSGI（Open Source Gateway Initiative）: 开放服务网关协议。

Graphite: 收集指标数据。
Nagios: 检测健康状态。

两个基于JVM的开源微容器: Dropwizard（http://dropwizard.io）和Karyon（https://github.com/Netiflix/karyon）

Vaughn Vernon《实现领域驱动设计》: 帮助理解如何实践领域驱动设计中提到的方法。

Richardson的成熟度模型: 对REST不同风格的比较。（http://martinfowler.com/articles/richardsonMaturityModel.html）

负载均衡器: mod_proxy

关于HTTP的REST，《REST实战》这本书对REST做了非常详细的介绍。

RabbitMQ: 消息代理

《企业集成模式》: 详细讨论了很多不同的编程模式。

Michael Feathers《修改代码的艺术》

Netflix实现了一个能够处理大量数据的流水线，并且开源了出来，它就是Aegisthus项目（htts://github.com/Netflix/aegisthus）。

Docker相关工具:
1）Google最近的开源工具Kubernetes和CoreOS集群技术。
2）Deis: 在Docker上提供类似于Heroku那样的Paas。

描术性文件格式: YAML

Jez Humble和David Farly《持续交付》: 此书对流水线设计和构建物管理有更深入的讨论。

关于测试的书: Brian Marick《敏捷软件测试》、Mike Cohn《Scrum敏捷软件开发》、弗里曼和普雷斯的《测试驱动的面向对象软件开发》

测试替身 - TestDouble: https://www.martinfowler.com/bliki/TestDouble.html

Python的web框架: Django

安全专家Bruse Schneier对于AES-256中的某些类型的密钥实现表示担心，相关文章:https://www.schneier.com/blog/archives/2009/07/another_new_aes.html

一个基于浏览器的应用程序安全的站点: 非营利OWASP（Open Web Application Security Project，开放式Web应用程序安全项目，http://www.owasp.org），其定期更新的十大安全风险文档，应被视为所有开发人员的必备读物。

更多密码学的读物: Niels Ferguson、Bruce Schneier和Tadayoshi Kohno所著的《Cryptography Engineering》。

缓存方面的书: 《REST实战》
HTTP1.1规范的第13章，描述了客户端和服务器应该如何实现不同的缓存控制手段: http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.3.3

推荐图书: Nygard《Release it!》: 在书里作者分享了一系列关于系统故障的故事，以及一些处理它们的模式。