微服务架构与实践--读书笔记
项目使用微服务已有两年多了，一直停留在使用层面，无意间发现这本书，想对其理论方面进行学习，以此读书笔记做简要记录。
作者：王磊
成书时间：2015年10月7日
示例代码语言：Ruby
运行环境：Mac OS(或Linux)
结构：
第一部分为基础部分。包括第1章和第2章，概述了三层应用架构以及微服务架构。
第二部分为实践部分。包括第3章至第10章，通过一个具体的实例，从头到尾介绍了一个服务从需求到实现，再到构建、部署以及运维的整个过程。
第三部分为进阶部分。包括第11章至第14章，讨论了微服务的持续交付、测试策略、通信机制，并描述了一个使用微服务改造遗留系统的真实案例。
三部分见相互独立，但各章节之前有前后依赖。
第一章 单块架构及其面临的挑战
软件三层架构：
- 表示层，聚焦数据显示和用户交互
- 业务逻辑层，聚焦业务逻辑处理
- 数据访问层，聚焦数据的存储与访问
虽然三层架构将系统的逻辑分成了三层，但他并不是物理上的分层。也就是说，对于不同层的代码而言，经历编译、打包、部署后，所有的代码最终还是运行在同一个进程中。
对于这种功能集中、代码中心化、一个发布包、部署后运行在同一进程的应用程序，我们通常称之为单块架构应用。
单块架构的优势
- 易于开发，大部分现有程序均采用单块架构，容易理解且为人熟知。现有IDE也比较多，方便开发人员开发、运行和调试等。
- 易于测试，所有功能均在一个进程，一旦部署，可立即进行系统测试或功能测试。
- 易于部署，形成一个软件包，部署容易
- 易于水平伸缩，更确切地理解其实是克隆，新建服务器节点可直接克隆之前节点即可。
单块架构面临的挑战
- 维护成本增加，功能越多团队越大，沟通成、管理成本以及协调成本必然会显著增加。另外组合缺陷也会随之增加，分析、定位、修复都将变得越发复杂。
- 持续交付周期长，随着程序功能越来越多，代码越来越复杂，构建和部署的时间也会相应增加。在修改以及提交代码时，都会触发已部署好的流水线，让其进行代码检查（包括编译、测试、代码检查、无害化验证等）。随着代码越多，功能验证越多，也就意味着提交所需时间越来越长。
- 新人培养周期长，熟悉功能、代码、环境都需要更长的周期。
- 技术选型成本高，随着复杂性的增加，如果团队希望尝试引入新的架构、技术，或者对现有技术栈升级，通常都会面临不小的风险。
- 可扩展性差，垂直扩展，水平扩展
- 构建全功能团队难，当功能越多，必不可少的会按功能划分任务，甚至团队。这样当一段时间后，会发现很少有人能掌握全景视图。
第二章 微服务架构综述
什么是微服务
对于微服务，目前业界还没有一个严格的定义。不过，ThoughtWorks的首席科学家——马丁·福勒(Martin Fowler)先生，对微服务的这段描述，似乎更加通俗易懂：
微服务是一种架构模式，他提倡将单一应用程序划分成一组小的服务，服务之间互相协调互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务之间采用轻量级的通信机制互相沟通（通常基于HTTP的RESTful API）。每个服务都围绕着业具体业务进行构建，并且能够独立的部署到成产环境、类生产环境等。另外，应当尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建。
多微才够微
代码行数：不同语言不同特点，代码行数无法衡量
重写时间：跟个人能力强相关，重写时间无法衡量
团队觉得好才是真的好：需要团队和组织找到平衡点，但应遵循以下两个基本原则
- 业务独立性：通过领域模型确定独立业务
- 团队自主性：能由不超过10人的全功能团队进行维护
独立性
独立性是指在应用的交付过程中，开发、测试以及部署的独立
进程隔离
理论上能够将多个服务部署到同一个节点，并让他们运行在不同的进程中，但并不推荐这个做。一方面增加了部署和扩展的复杂度，另一方面会给水平扩容带来麻烦。
诞生背景
容器虚拟化技术
Docker是一个开源的应用容器（Linux Container）引擎。
优势：
- 更快速的交付和部署
- 更轻松地迁移和扩展
- 更简单的管理
微服务架构与SOA
SOA(Service-Oriented Architecture)：面向服务架构，早在1996年由Gartner提出。对于复杂的企业IT系统，应按照不同的、可重用的力度划分，将功能相关的一组功能提供者组织在一起为消费者提供服务。
SOA与微服务的区别
| SOA实现 | 微服务实现 |
|---|---|
| 企业级，自顶向下开展实施 | 团队级，自底向上开展实施 |
| 服务由多个子系统组成，粒度大 | 一个系统被拆分成多个服务，粒度细 |
| 企业服务总线，集中式的服务架构 | 无集中式总线，松散的服务架构 |
| 集成方式复杂（ESB/WS/SOAP） | 集成方式简单（HTTP/REST/JSON） |
| 单块架构系统，互相依赖，部署复杂 | 服务能独立部署 |
微服务架构是传统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
大的系统组织总是比小系统更倾向于分解
