项目使用微服务已有两年多了，一直停留在使用层面，无意间发现这本书，想对其理论方面进行学习，以此读书笔记做简要记录。
作者：王磊
成书时间：2015年10月7日
示例代码语言：Ruby
运行环境：Mac OS(或Linux)

结构：
第一部分为基础部分。包括第1章和第2章，概述了三层应用架构以及微服务架构。
第二部分为实践部分。包括第3章至第10章，通过一个具体的实例，从头到尾介绍了一个服务从需求到实现，再到构建、部署以及运维的整个过程。
第三部分为进阶部分。包括第11章至第14章，讨论了微服务的持续交付、测试策略、通信机制，并描述了一个使用微服务改造遗留系统的真实案例。

三部分见相互独立，但各章节之前有前后依赖。

第一章 单块架构及其面临的挑战

软件三层架构：

• 表示层，聚焦数据显示和用户交互
• 业务逻辑层，聚焦业务逻辑处理
• 数据访问层，聚焦数据的存储与访问

虽然三层架构将系统的逻辑分成了三层，但他并不是物理上的分层。也就是说，对于不同层的代码而言，经历编译、打包、部署后，所有的代码最终还是运行在同一个进程中。

对于这种功能集中、代码中心化、一个发布包、部署后运行在同一进程的应用程序，我们通常称之为单块架构应用。

单块架构的优势

• 易于开发，大部分现有程序均采用单块架构，容易理解且为人熟知。现有IDE也比较多，方便开发人员开发、运行和调试等。
• 易于测试，所有功能均在一个进程，一旦部署，可立即进行系统测试或功能测试。
• 易于部署，形成一个软件包，部署容易
• 易于水平伸缩，更确切地理解其实是克隆，新建服务器节点可直接克隆之前节点即可。

单块架构面临的挑战

• 维护成本增加，功能越多团队越大，沟通成、管理成本以及协调成本必然会显著增加。另外组合缺陷也会随之增加，分析、定位、修复都将变得越发复杂。
• 持续交付周期长，随着程序功能越来越多，代码越来越复杂，构建和部署的时间也会相应增加。在修改以及提交代码时，都会触发已部署好的流水线，让其进行代码检查（包括编译、测试、代码检查、无害化验证等）。随着代码越多，功能验证越多，也就意味着提交所需时间越来越长。
• 新人培养周期长，熟悉功能、代码、环境都需要更长的周期。
• 技术选型成本高，随着复杂性的增加，如果团队希望尝试引入新的架构、技术，或者对现有技术栈升级，通常都会面临不小的风险。
• 可扩展性差，垂直扩展，水平扩展
• 构建全功能团队难，当功能越多，必不可少的会按功能划分任务，甚至团队。这样当一段时间后，会发现很少有人能掌握全景视图。

第二章 微服务架构综述

什么是微服务

对于微服务，目前业界还没有一个严格的定义。不过，ThoughtWorks的首席科学家——马丁·福勒(Martin Fowler)先生，对微服务的这段描述，似乎更加通俗易懂：

微服务是一种架构模式，他提倡将单一应用程序划分成一组小的服务，服务之间互相协调互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务之间采用轻量级的通信机制互相沟通（通常基于HTTP的RESTful API）。每个服务都围绕着业具体业务进行构建，并且能够独立的部署到成产环境、类生产环境等。另外，应当尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建。

https://martinfowler.com/articles/microservices.html

多微才够微

代码行数：不同语言不同特点，代码行数无法衡量
重写时间：跟个人能力强相关，重写时间无法衡量
团队觉得好才是真的好：需要团队和组织找到平衡点，但应遵循以下两个基本原则

• 业务独立性：通过领域模型确定独立业务
• 团队自主性：能由不超过10人的全功能团队进行维护

独立性

独立性是指在应用的交付过程中，开发、测试以及部署的独立

进程隔离

理论上能够将多个服务部署到同一个节点，并让他们运行在不同的进程中，但并不推荐这个做。一方面增加了部署和扩展的复杂度，另一方面会给水平扩容带来麻烦。

诞生背景

容器虚拟化技术
Docker是一个开源的应用容器（Linux Container）引擎。
优势：

• 更快速的交付和部署
• 更轻松地迁移和扩展
• 更简单的管理

微服务架构与SOA

SOA(Service-Oriented Architecture)：面向服务架构，早在1996年由Gartner提出。对于复杂的企业IT系统，应按照不同的、可重用的力度划分，将功能相关的一组功能提供者组织在一起为消费者提供服务。
SOA与微服务的区别

微服务架构是传统SOA的一个子集

微服务的本质

• 服务作为组件：传统实现组件的方式是隔离独立的部分或抽取公用的部分，构建共享库，从而达到解耦和复用的效果。但它通常是语言相关、平台相关，并且运行在同一个进程中的。换句话说共享库的变化意味着整个应用要被更新，并且需要重新部署。如果把微服务作为组件，则同传统使用组件方式最大的区别是，组件可以被独立部署。另外一个优点是组件间定义了清晰的、平台无关的接口。缺点：耗时，严重依赖网络的可靠性与稳定性。
• 围绕业务组织团队：单块架构按技能划分团队，微服务架构按业务划分团队，团队中的成员具有多样性的技能。如康威定律描述。
• 关注产品而非项目：单块架构大多采用项目模式，即项目启动时，从资源池中抽取人员，组成团队并完成项目。这样缺乏主人翁意识、没有有效的奖惩机制、缺乏产品成就感。微服务架构采用产品模式更倾向于让团队负责整个服务的生命周期。从服务的分析、开发、测试、部署、运维。You build it, you run it. --Werner Vogels, CTO of Amazon
• 技术多样性：在微服务架构中提倡针对不同的业务特征选择合适的技术方案。
• 业务数据独立：微服务架构提倡服务自主管理其相关的数据。
• 基础设施自动化：微服务架构将应用程序本身分成多个小的服务，部署和运维的成本会随着服务的增长成指数级增长，就需要更稳定的基础设置自动化机制，能够创建运行环境，安装依赖，部署应用等。可借助云技术。
• 演进式架构：服务能独立运行在不同的进程中，并且通过轻量级的通信机制建立联系，这样在演进过程中可先用一个或几个简单的服务进行试点，可用则推广，不可用回退成本也比较低。

微服务不是银弹

银弹：是指一项可使软件工程的生产力在十年内提高十倍的技术或方法
优势：

• 独立性
• 单一职责
• 技术多样性

需要考虑的因素：

• 分布式系统的复杂度
• • 性能
  • 可靠性
  • 异步
  • 数据一致性
  • 工具
• 运维成本
• • 配置
  • 部署
  • 监控与告警
  • 日志收集
• 部署自动化
• DevOps与组织架构
• 服务间的依赖测试
• 服务间依赖管理

后两部分，待续。。。

附：

康威定律

Conway’s law 最初来自于Conway在1967年发表的论文《How Do Committees Invent?》，之后在《人月神话》这本书中引用了论文的结论，并命名为康威定律（Conway’s law）得以推广。

Conway’s law: Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations. - Melvin Conway(1967)

我的翻译：设计系统的组织形式受制于产品设计，沟通结构也等价于该组织形式。

我的理解：团队划分或者项目组织需要根据设计的产品进行组织，而一旦该组织形式确定，其沟通成本也随之确定。
在文章中，Mike Amundesn总结了一些核心观点：

• 第一定律

Communication dictates the design组织沟通方式会通过系统设计表达出来

• 第二定律

There is never enough time to do something right, but there is always enough time to do it over

时间再多一件事情也不可能做的完美，但总有时间做完一件事情

• 第三定律

There is a homomorphism from the linear graph of a system to the linear graph of its design organization

线型系统和线型组织架构间有潜在的异质同态特性

• 第四定律

The structures of large systems tend to disintegrate during development, qualitatively more so than with small systems

大的系统组织总是比小系统更倾向于分解