未来一定是分布式的
Architecting for Scale: How to Maintain High Availability and Manage Risk in the Cloud 2nd Edition
Author : Lee Atchison
Publisher : O'Reilly Media; 2nd edition (March 24, 2020)
Language : English
Paperback : 268 pages
ISBN-10 : 1492057177
ISBN-13 : 978-1492057178
2021年3月24日，全球最大的公有云服务商 AWS 的 CEO
Andy Jassy 给AWS全体员工发了一封公开信。
他在这封信中提到：
目前，全球 IT 支出中只有不到 5% 在云中。
Less than 5% of the global IT spend is in the cloud at this point.
这是一个让人吃惊的数字。
特别是在企业级场景，仍然有大部分的业务的工作负载运行在传统架构之上。
但是，我们听到春雷阵阵。
企业IT的每一层，包括应用层、中间件/中台、系统平台、基础设施都在发生变革。
典型的特征就是能够支撑大规模场景的分布式架构。
这是一本比较容易阅读的书。
它的主题是分布式架构的设计思路，比较清晰，有条理。
让我觉得应该翻译为中文出版。
但是，作者有AWS的工作经历，所以最后部分主要在讲云和AWS的应用，我不太认同。
标题：Architecting for Scale
副标题：How to Maintain High Availability and Manage Risk in the Cloud
两个标题都比较好地表达了分布式架构设计的本质，也即本书的主题。
Scale - 扩展性，在不同场景下的扩展，例如升级、故障等
High Availability - 怎么体现在架构设计上。。
Manage Risk - 风险管理是架构设计的一部分
第一章：Availability: Maintaining Availability in Modern Applications
Without high availability, you have no reason to scale.
--这句话说的比较经典。高可用是现代化架构设计的基本点。
--常见的场景：把应用程序部署在云上的虚拟机中，并没有实现高可用架构，只是资源更充足了而已。
Availability V.S. Reliability
--可用性，经常提到的几个9是指的可用性，即在规定时间内系统可用的时间与总时间的比率；
--可靠性，系统能够正常执行并输出正确的结果的能力，即无故障的情况，与故障率相关；
Planned Outage Are Still Outages.
--这也是我经常提醒大家的：计划内停机也是停机。
--从架构设计上考虑有很多工作要做，作者提出如下建议：
---Measure and track your current availability
---Automate your manual processes
---Automate your deployment processes
---Maintain and track all configurations in a management system
---Allow quick changes and experiments, with an easy rollback capability if a problem occurs
---Aim to continuously improve your applications and systems
---Keep on top of availability as a core issue as your application changes and grows
Five Focuses to Improve Application Availability
--1. Build with failure in mind
--2. Always think about scaling
--3. Mitigate risk
--4. Monitor availability
--5. Respond to availability issues in a predictable and defined way
Two Mistakes High
--在控制航模飞机的飞行时，要让飞机在至少“两个错误”的高度，也就是说在处理第一次错误时，如果再发生第二次另外的错误，仍有足够的下落的时间来处理，确保飞机不会坠毁
--无疑这是一个极佳的例子，可以应用到架构设计中，考虑下面的场景：
---场景1.一个节点失败，如果在处理过程中，再一个节点失败，如何保证服务能力可用性？
---场景2.升级中失败，这个让我想起若干年前某宇宙大行升级失败导致全国大面积核心系统故障
---场景3.数据中心级故障，如何处理多个数据中心之间、跨集群之间的可用性？
---场景4.未知的关联性故障，很多时候，表面看起来不会相关的故障，但无故同时发生了。。
---场景5.循环故障，解决一个问题带来更多问题。。。
第二章：Modern Application Architecture: Using Services
The Monolith Application Versus the Service-Based Application
--传统架构的应用与服务化应用的主要区别是模块间的耦合度
Dividing into Services 推荐原则：
--1. Specific Business Requirements
--2. Distinct and Separable Team Ownership
--3. Naturally Separable Data
--4. Shared Capabilities/Data
Dealing with Service Failures
--关键的因素是服务之间有依存关系，故障会引发连锁反应，如何在设计中考虑故障的应对
第三章：Organization: Scaling Your Organization
Single Team Oriented Service Architecture (STOSA)，直接看图就明白这个意思了。
服务的分层
--上面提到，服务之间有依存关系，同时更重要的是不同的服务对最终客户相应的重要程度不同。这一定要从业务影响等级去判断。比如，一个在线商店，商品图片显示的服务一般非常重要，因为即使客户能正常打开页面，正常下单，但是一般人不看到图片是不会购买的。
--所以，重要的是：1.画出服务之间的关联图；2.把服务标识上相应的等级；3.综合这两点把服务归类，即考虑不同的系统设计和可用性方法
SLA Versus SLO
--这是错的：SLA是对外的服务承诺，SLO是内部执行的要求，所以SLO不如SLA重要。
--顺序应该是颠倒过来，SLO更重要一点，不然SLA没法实现。
--其实没必要说SLO，都作为SLA挺好。
--SLA是一个复杂的话题，重点：1. 系统运行有波峰波谷，不能低于SLA的底限；2.要详细分析内部调用的SLA，和影响因素，因为对外的SLA是内部所有的叠加
第四章：Risk: Risk Management for Modern Applications
金句：You cannot possibly manage the risk in your system if you cannot identify the risk in your system.
Risk Matrix
--作者讲了很多关于如何分析、收集、和审查 risk的建议办法。但是具体执行要看具体情况。因为 risk management 本身就是一个很大的话题，有专业的一些方法论和框架可参考。
Risk Mitigation, Recovery Plans, Disaster Recovery Plan
--简单总结就是在设计之初，就要想好应对之策，而不是系统上线之后的应对办法。
Game Day
--作者应该是借用了AWS架构设计最佳实践中，关于系统故障测试的方法。
https://wa.aws.amazon.com/wellarchitected/2020-07-02T19-33-23/wat.concept.gameday.en.html
Chaos Monkey
--早先 Netflix 使用的方法，即使像在系统内放入一个猴子一样，大闹天空，产生一些随机的故障，以测试系统。
--https://netflix.github.io/chaosmonkey/
第五章：Cloud: Utilizing the Cloud
这一章作者以AWS为样板，讲云服务。关于云基础设施的资源管理、Serverless 和 FaaS、以及使用云要注意其地理位置内容不错。关于边缘计算（如无人机驾驶汽车）讲的比较简单。
作者应该有丰富的分布式和云架构设计经验。
同时，这本书写的非常简单易懂，不是那么技术化，也不是纯粹理论化。
对当前的系统架构设计有借鉴意义。