《springcloud&学习资料》--讨论如何构建一套可靠的大型分布式系统.zip

# ArchSummit2021主题演讲：从软件的历史看架构的未来 1972 年，[Edsger Dijkstra](https://en.wikipedia.org/wiki/Edsger_W._Dijkstra) 在为图灵奖颁授典礼所写的[感言文章](https://www.cs.utexas.edu/users/EWD/transcriptions/EWD03xx/EWD340.html)中说到：“在没有计算机的时候，也就没有编程问题；当我们有了简单的计算机，编程只是个小问题；而现在我们有了算力规模庞大的计算机，那编程就成为了一个同样巨大的问题了”。半个世纪前，Dijkstra 已经敏锐洞见了机器算力的提升是编程方法发展的直接牵引，每当人类掌握了更强的算力，便按捺不住想去解决一些以前甚至都不敢去设想的新问题，由此引发软件设计模式的重大变革。 ## 历史上的软件危机和契机 计算机刚诞生的年代，硬件规模还很小，甚至程序员仅凭大脑就足够记住数据在几 KB 内存中的布局情况，理解每条指令在电路中的运行逻辑。此时的计算机尽管运算速度比人类快，但内部却并没有什么人所不知道的事情；此时的软件开发并没有独立的“架构”可言，软件架构与硬件架构是直接物理对齐的。 随着计算机的快速发展，直接面向硬件进行的软件开发很快触碰到了瓶颈，人脑的生物局限显然无法跟上机器算力前进的步伐，当机器强大到世界上最聪明的人都无法为它编写出合适的程序了，那计算机科学还能继续发展吗？这便是历史上第一次软件危机的根源。第一次软件危机，同时也是[结构化编程](https://en.wikipedia.org/wiki/Structured_programming)发展的契机，结构化编程扭转了当时直接面向全局数据、满屏 Goto 语句书写[面条式代码](https://en.wikipedia.org/wiki/Spaghetti_code)（Spaghetti Code）的编程风气，强调可独立编写、可重复利用的子过程/局部块的重要性，让软件的每个局部都能够设计专门的算法和数据结构，允许每一位程序员只关注自己所负责的部分，从而在整体上控制住了软件开发的复杂度。此时，软件的架构才开始独立于硬件物理架构而存在，软件业开始出现把控全局设计的架构师与聚焦局部实现的程序员的角色分工。 将软件从整体划分成若干个局部，人类能够以群体配合来共同开发软件，使得人与计算机又和谐共处了十余年。不过，机器的算力膨胀仍然在持续，人类群体的沟通协作能力却终有极限。人毕竟不是可复制的程序，每个人都有自己的理解与认知，如何让各个模块能准确地协同工作成了一场灾难，这就是第二次软件危机的根源。《[人月神话](https://en.wikipedia.org/wiki/The_Mythical_Man-Month)》中有一个几乎每位程序员都听过的案例：IBM 公司为开发 OS/360 系统投入的成本达到了美国的“曼哈顿”原子弹计划的 25%，共有 4000 多个模块，约 100 万条指令，超过 5000 人年，耗资数亿美元，即使如此，结果还是延期交付，在交付使用后的系统中仍发现大量的缺陷。 渡过第二次软件危机的过程中，面向对象编程逐步取代了面向过程的结构化编程，成为主流的程序设计思想，这次思想转变宣告“追求最符合人类思维的视角来抽象问题”取代了“追求最符合机器运行特征的算法与数据结构”成为软件架构的最高优先级，并一直持续沿用至今。这次危机还直接导致软件工程的诞生， 如何以系统性的、规范化的、可定量的方法去高质量地开发和维护软件成为一门独立的科学。 ## 云与分布式渐成为主流 如果说历史上的第一、二次软件危机分别是机器算力规模超过了人类个体的生理极限，超过了人类群体的沟通极限的话。那么在今天，在云计算的时代，数据中心所能提供的算力其实已经逼近到了人类协作的工程极限，与此算力相符的程序规模，几乎也到了无论采用何种工程措施去优化过程、无论采用什么管理手段去提升质量，都仍然不可避免会出现意外与异常的程度。大家都相信只要软件系统由大量人员共同研发，并使其分布在云中大量节点协同运行，随着项目规模的增大、时间变长，就肯定会有人疏忽犯错，会有代码携带缺陷，会有电脑宕机崩溃，会有网络堵塞中断，总之，必然会受到墨菲定律的无情打击。 软件架构要与硬件算力规模对齐，目前用来适配云计算与分布式的主流架构形式是微服务，微服务兴起之时，曾涌现出各类文章去总结、赞美微服务带来的种种好处，诸如简化部署、逻辑拆分更清晰、便于技术异构、易于伸缩拓展应对更高的性能，等等，这些当然都是重要优点。可是，如果不拘泥于特定场景特定问题，以宏观的角度来看，前面所列这种种好处都只算是“锦上添花”、是属于让系统“更好”的动因，肯定比不上系统如何确保“生存”来得关键。在笔者看来，从单体到微服务的最根本的推动力，是为了方便某个服务能够顺利地“消亡”与“重生”，局部个体的生死更迭，是关系到整个系统能否可靠续存的关键因素。 举个例子，在很长的时间里面，企业应用中采用单体架构的 Java 系统，其更新、升级都必须要有固定的停机计划，必须在特定的时间窗口内才能按时开始，必须按时结束。如果出现了非计划的宕机，那便是生产事故。但是软件的缺陷不可能遵循停机计划来“安排时间出错”，为了应对缺陷与变化，做到不停机的检修，Java 曾经搞出了 OSGi 和 JVMTI Instrumentation 等复杂的 HotSwap 方案，以实现给奔跑中的汽车更换轮胎这种匪夷所思却又无可奈何的需求；而在微服务架构的视角下，所谓系统检修，充其量只是一次服务滚动更新而已，灰度部署新的程序版本，然后导流、测试、发布即可。 流水不腐，有老朽，有消亡，有重生，有更迭才是生态运行的合理规律，如何采用不可靠的部件来构造出一个可靠的系统，是软件架构适配云与分布式算力发展的关键所在。如果系统中局部能拥有独立的生命周期，在整体架构上有物理隔离的设计，那即便采用了不可靠部件，在系统外观察，整体上仍然有可能表现出稳定健壮的服务能力。 ## 从云计算到云不可知 我们继续顺着”软件架构的演进由人与机器的矛盾所驱动，逐渐与算力规模对齐“这条线索，思考软件开发的下一个核心矛盾将会是什么？窥探下一个时代的软件架构会具备何种特征？ 笔者认为，软件发展的下一个关键矛盾将会是算力规模超过人应掌握合理知识的极限。经过良好设计的分布式系统，拥有局部的可再生性，确实能在整体上展现出可靠的服务能力。然而，“良好地设计”一个分布式系统很不容易，今天无限火热的云原生、微服务、不可变基础设施、弹性计算、服务网格、无服务器架构、高低零代码，等等，背后都能展开成一整套成体系的开发或者设计方法。这些新的技术在为人们解决了更复杂软件问题的同时，也正在把编程这件事情本身的复杂度推向更高层次。一名刚刚走出校园的大学生，要掌握计算机与程序执行的基本原理，要消化完所用编程语言的核心细节，要掌握领域中常用的类库、框架和工具，要理解分布式系统的服务弹性、容错、限流等设计技巧，要接触容器、云原生、函数计算等运行架构层面的知识，耗费上十年时间都丝毫不奇怪。 在哲学里，有人曾�