微服务架构与实践--读书笔记

项目使用微服务已有两年多了，一直停留在使用层面，无意间发现这本书，想对其理论方面进行学习，以此读书笔记做简要记录。
作者：王磊
成书时间：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实现	微服务实现
企业级，自顶向下开展实施	团队级，自底向上开展实施
服务由多个子系统组成，粒度大	一个系统被拆分成多个服务，粒度细
企业服务总线，集中式的服务架构	无集中式总线，松散的服务架构
集成方式复杂（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

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