#阅读# #学习笔记# 《第一章读书笔记》 服务架构演进史 《https://wx.zsxq.com/mweb/views/weread/search.html?keyword=凤凰架构》是周志明大佬撰写的一部关于如何构建可靠的大型分布式系统的技术书籍，非常硬核，挑战4月份读完并连续发布读书笔记📒！ 这是一本从架构视角讲解如何构建大型分布式系统的著作，是超级畅销书《https://wx.zsxq.com/mweb/views/weread/search.html?keyword=深入理解Java虚拟机》的作者周志明多年架构和研发经验的总结，得到了多位行业资深架构专家的联袂推荐。 全书共16章，分为演进中的架构、架构师的视角、分布式的基石、不可变基础设施和技术方法论五部分。 全书以实践为导向，一个案例贯穿全书，同时给出了基于Spring Boot、Spring Cloud、Kubernetes、Istio、AWS Lambda 五种架构风格的样例工程。 【第一章 服务架构演进史】 1、架构演进 原始分布式时代。当时计算机硬件局促的运算处理能力，已直接妨碍到了在单台计算机上信息系统软件能够达到的最大规模。为突破硬件算力的限制，各个高校、研究机构、软硬件厂商开始分头探索，寻找使用多台计算机共同协作来支撑同一套软件系统运行的可行方案。这一阶段是对分布式架构最原始的探索。 调用远程方法遇到的问题，比如，远程的服务在哪里(服务发现)，有多少个(负载均衡)，网络出现分区、超时或者服务出错了怎么办(熔断、隔离、降级)，方法的参数与返回结果如何表示(序列化协议)，信息如何传输(传输协议)，服务权限如何管理(认证、授权)，如何保证通信安全(网络安全层)、如何令调用不同机器的服务返回相同的结果(分布式数据一致性)。 单体系统时代。系统各个模块都是在同一进程内调用。由于所有代码都共享同一进程，不能隔离，也就无法做到单独停止，更新，升级某一部分代码。从可维护性来说，单体系统是不占优势的。 SOA时代。也就是面向务架构(Service Oriented Architecture) ， 对大型系统行拆分，让每个子系统都能独立部署运行更新。SOA流程过于复杂，无法广泛推广。 微服务时代。微服务是一种通过多个小型服务组合来构建个应用的架构风格。这些服务围绕业务能力非特定技术标准来构建。各个服务可以采用不同的编程语言、不同数据存储技术，运行在不同进程之中。服务采取轻量级通信机制自动化部署机制实现通信和运维。 微服务架构需要考虑的问题：服务发现、跟踪治理、负载均衡、故障隔离、认证授权、伸缩扩展等。 微服务的业务与技术特征：1.围绕业务能力构建;2.分散治理; 3. 通过服务来实现独立自治的组件;4.产品化思维; 5.数据去中心化; 6.强终端弱管道;7.容错性设计;8演进式设计;9基础设施自动化; 后微服务时代。容器化 docker，虚拟化技术 Kubernetes，服务风格 Service Mesh， 云原生. 无服务时代。Serverless。让开发者只关注业务，不需要考虑技术组件，数据库、MQ、日志、存储等设施都运行在云上。 2、微服务概念： 现代微服务的概念：“微服务是一种通过多个小型服务组合来构建单个应用的架构风格，这些服务围绕业务能力而非特定的技术标准来构建。各个服务可以采用不同的编程语言，不同的数据存储技术，运行在不同的进程之中。服务采取轻量级的通信机制和自动化的部署机制实现通信与运维。” 微服务的九个核心的业务与技术特征： 围绕业务能力构建（Organized around Business Capability）。 这里再次强调了康威定律的重要性，有怎样结构、规模、能力的团队，就会产生出对应结构、规模、能力的产品。这个结论不是某个团队、某个公司遇到的巧合，而是必然的演化结果。如果本应该归属同一个产品内的功能被划分在不同团队中，必然会产生大量的跨团队沟通协作，跨越团队边界无论在管理、沟通、工作安排上都有更高昂的成本，高效的团队自然会针对其进行改进，当团队、产品磨合调节稳定之后，团队与产品就会拥有一致的结构。 分散治理（Decentralized Governance）。 这是要表达“谁家孩子谁来管”的意思，服务对应的开发团队有直接对服务运行质量负责的责任，也应该有着不受外界干预地掌控服务各个方面的权力，譬如选择与其他服务异构的技术来实现自己的服务。这一点在真正实践时多少存有宽松的处理余地，大多数公司都不会在某一个服务使用Java，另一个用Python，下一个用Golang，而是通常会有统一的主流语言，乃至统一的技术栈或专有的技术平台。 微服务不提倡也并不反对这种“统一”，只要负责提供和维护基础技术栈的团队，有被各方依赖的觉悟，要有“经常被凌晨3点的闹钟吵醒”的心理准备就好。微服务更加强调的是确实有必要技术异构时，应能够有选择“不统一”的权利，譬如不应该强迫 Node.js去开发报表页面，要做人工智能训练模型时，应该可以选择 Python，等等。 通过服务来实现独立自治的组件（Componentization via Services）。 之所以强调通过“服务”（Service）而不是“类库”（Library）来构建组件，是因为类库在编译期静态链接到程序中，通过本地调用来提供功能，而服务是进程外组件，通过远程调用来提供功能。前面的文章里我们已经分析过，尽管远程服务有更高昂的调用成本，但这是为组件带来隔离与自治能力的必要代价。 产品化思维（Products not Projects）。 避免把软件研发视作要去完成某种功能，而是视作一种持续改进、提升的过程。譬如，不应该把运维只看作运维团队的事，把开发只看作开发团队的事，团队应该为软件产品的整个生命周期负责，开发者不仅应该知道软件如何开发，还应该知道它如何运作，用户如何反馈，乃至售后支持工作是怎样进行的。 注意，这里服务的用户不一定是最终用户，也可能是消费这个服务的另外一个服务。以前在单体架构下，程序的规模决定了无法让全部人员都关注完整的产品，组织中会有开发、运维、支持等细致的分工的成员，各人只关注于自己的一块工作，但在微服务下，要求开发团队中每个人都具有产品化思维，关心整个产品的全部方面是具有可行性的。 数据去中心化（Decentralized Data Management）。 微服务明确地提倡数据应该按领域分散管理、更新、维护、存储，在单体服务中，一个系统的各个功能模块通常会使用同一个数据库，诚然中心化的存储天生就更容易避免一致性问题，但是，同一个数据实体在不同服务的视角里，它的抽象形态往往也是不同的。 譬如，Bookstore应用中的书本，在销售领域中关注的是价格，在仓储领域中关注的库存数量，在商品展示领域中关注的是书籍的介绍信息，如果作为中心化的存储，所有领域都必须修改和映射到同一个实体之中，这便使得不同的服务很可能会互相产生影响而丧失掉独立性。尽管在分布式中要处理好一致性的问题也相当困难，很多时候都没法使用传统的事务处理来保证，但是两害相权取其轻，有一些必要的代价仍是值得付出的。 强终端弱管道（Smart Endpoint and Dumb Pipe）。 弱管道（Dumb Pipe）几乎算是直接指名道姓地反对 SOAP和ESB的那一堆复杂的通信机制。ESB可以处理消息的编码加工、业务规则转换等；BPM 可以集中编排企业业务服务；SOAP有几十个WS-*协议族在处理事务、一致性、认证授权等一系列工作，这些构筑在通信管道上的功能也许对某个系统中的某一部分服务是有必要的，但对于另外更多的服务则是强加进来的负担。如果服务需要上面的额外通信能力，就应该在服务自己的Endpoint 上解决，而不是在通信管道上一揽子处理。微服务提倡类似于经典UNIX过滤器那样简单直接的通信方式，RESTful 风格的通信在微服务中会是更加合适的选择。 容错性设计（Design for Failure）。不再虚幻地追求服务永远稳定，而是接受服务总会出错的现实，要求在微服务的设计中，有自动的机制对其依赖的服务能够进行快速故障检测，在持续出错的时候进行隔离，在服务恢复的时候重新联通。所以“断路器”这类设施，对实际生产环境的微服务来说并不是可选的外围组件，而是一个必须的支撑点，如果没有容错性的设计，系统很容易就会被因为一两个服务的崩溃所带来的雪崩效应淹没。可靠系统完全可能由会出错的服务组成，这是微服务最大的价值所在，也是这部开源文档标题“凤凰架构”的含义。 演进式设计（Evolutionary Design）。 容错性设计承认服务会出错，演进式设计则是承认服务会被报废淘汰。一个设计良好的服务，应该是能够报废的，而不是期望得到长存永生。假如系统中出现不可更改、无可替代的服务，这并不能说明这个服务是多么的优秀、多么的重要，反而是一种系统设计上脆弱的表现，微服务所追求的独立、自治，也是反对这种脆弱性的表现。 基础设施自动化（Infrastructure Automation）。 基础设施自动化，如 CI/CD 的长足发展，显著减少了构建、发布、运维工作的复杂性。由于微服务下运维的对象比起单体架构要有数量级的增长，使用微服务的团队更加依赖于基础设施的自动化，人工是很难支撑成百上千乃至成千上万级别的服务的。