Werner表示,复杂性总是会“悄无声息”地渗透进来,让系统变得更加复杂。复杂性本身是件好事,因为它意味着添加更多功能。所以“复杂性”并不是问题,而“管理复杂性”才是个问题。
简化从两块Pizza开始!
Werner开场视频讲述了世界上最大的存储系统之一Amazon S3的故事,以及通过Two-Pizza team工作法,保有高效创新的团队。“每年我都被大家的热情所感染”,Werner说自己参与过13次re:Invent大会,在2012年首届亚马逊云科技re:Invent大会上首次提出的“21世纪架构”的理念,今年——Werner引入了“繁简之道”(The Way of Simplexity)的概念:“要真正控制你的系统,你需要管理复杂性。”
经验1
Werner指出,构建可控演进的架构,是应对复杂性、生存下去的关键所在。他以Amazon S3为例,当团队开始构建亚马逊简单存储服务Amazon S3时,“我们就知道一年后不会使用同样的架构。”从表面上看Amazon S3系统很简单,但在底层越来越复杂。2006年推出时,它只有6个微服务,现在已经超过300个。
拓展系统,看起来似乎很简单,但其实,随着其内在复杂度的增加,难度与日俱增。我们无法预知未来,但可以设计出灵活、可扩展的架构,以应对未知的挑战。这不仅需要远见卓识的技术规划,更需要对架构本身和技术不断打磨。
只有构建出能够以可控方式演进的系统架构,我们才能从容应对复杂性的持续变化,在保证系统核心价值的同时,不断融入创新,满足不断升级的需求。这正是亚马逊云科技等科技巨头在架构设计上的重中之重,也是每个技术团队都应该重视和学习的宝贵经验。
经验2
Werner以Amazon CloudWatch为例,解释亚马逊云科技是如何将庞大服务分解为可演进的小模块。Amazon CloudWatch是实时监控亚马逊云科技资源运行的应用程序,随着系统不断扩展,Amazon CloudWatch作为亚马逊云科技关键基础服务之一,每天有成百上千亿的指标,复杂性也达到了新的高度。亚马逊云科技通过将Amazon CloudWatch拆分为一系列低耦合、高内聚的小组件,并定义良好的API接口,提供非常简单的前端服务。该服务经过一次次重写,在为客户提供新功能的同时,并不会带来中断。
“去大化小”的架构思路,将复杂的大系统分解为简单、灵活、可组合的微服务,这是应对复杂性的可演进路径。每个小型组件的职责明确,变更成本低,可以通过组件的不断优化而持续演进,并在关键时刻平滑过渡,避免服务中断。在遇到新功能时,既可以在现有功能上进行扩展,也可以创建一个新的微服务来实现,如果我们扩展现有代码,通常会更快,但需要冒着复杂度增加并产生超级服务的风险;如果创建新的微服务,则需要更长的开发时间,但可以保持服务的复杂度可控。
经验3
亚马逊云科技副总裁及杰出工程师Andy Barfield登台加入Werner演讲,阐释了第三条经验。他表示,Amazon S3服务已经存在18年了,在构建越来越复杂系统的同时,必须承认,组织的复杂性与正在构建的软件一样复杂。
第二,主人翁精神。交给团队一个问题,并赋予他们决策权和空间去解决它。领导者的职责是赋予团队决策权,同时保持一种紧迫感,帮助他们按时交付。
一方面要赋能团队,授权并信任他们;另一方面也要建立良好的问责机制,营造积极向上的文化氛围,推动持续改进。只有组织与技术架构相互匹配、相互支撑,才能真正释放团队的创新活力,攻克复杂性。
经验4
Werner强调,确保复杂性可控也至关重要,方法是:采用基于单元的架构(Cell-based Architectures),将系统拆分为更小的独立单元。这些基础单元的颗粒度比传统团队更小、职责更明确。同时独立运作的细小单元,能更精确的控制“爆炸范围”。一旦发生故障或需要升级,只会波及到该单元本身,避免了连锁反应导致整个系统瘫痪。
Werner结合亚马逊实践,深入阐释了设计哲学。理想情况下,一个单元应该足够大,能处理可想象的最大工作负载,但也要足够小,以便全面测试。这是一个权衡。但最终的衡量标准是,是否有助于长期维护可靠性和安全性,并减少对客户影响。单元化设计是提高系统可靠性、弹性和安全性的有力手段。通过将复杂的大型系统分解为相对独立的单元,每个单元的故障影响就被隔离。单个单元也更易于管理、测试和演进。
借助单元化架构设计思想,配合云原生技术如容器和服务网格,就能在降低复杂性的同时,最大程度提高系统的可靠性和弹性,真正为客户提供始终如一的优质体验。其最佳实践在《What is a cell-based architecture》一文中有所阐述[1]。
经验5
Werner指出,不确定性是管理复杂度的另一关键问题。不确定性通常很难处理,想象一下:你的任务是设计一个配置系统,但是现有系统的客户正在不断地重新配置他们的任务和参数,而且客户的数量级是数以百万计;这时,一种常见的方法是使用小规模事件驱动的体系结构,更改配置并存储在数据库中。每发送一个事件或队列,我们就相应调整系统。但如果这种情况持续发生,系统负载均衡所必须承担的重新配置的负载量,就会变得相当可怕。
但是,我们所采用是一种更简单的方法,将所有的调整存储在一个文件中,该文件包含一组固定的记录,负载均衡器在固定的循环中,每隔几秒钟从该文件中获取新的配置,并处理所有记录。此时重新配置就是完全可预测的,可简单地构建高度可预测系统,持续地从Amazon S3中取出一个文件,避免积压、瓶颈,自然而然地自我修复——这就是持续工作模式。
另一个利用持续工作模式的例子是Amazon Route53的健康检查。配置健康检查之后,无论节点是否可用,健康状况检查器只会定期推送出完整的配置文件到聚合器,聚合器合并所有请求,然后将其推送到一个更大的表中,并推送Amazon Route53。这就实现了不会每次都触发调整,只有当DNS请求到达并被解析到一组IP地址时,系统才会检查表中的记录。这样,系统就是高度可预测的。而这是特意设计出来的。化繁为简需要有意识地配置和调整,设计可预测的系统,以减少不确定性。
经验6
“自动化是另一条重要经验”,Werner说。有些过程需要人工参与,但对于大量功能而言,自动化是关键所在。Werner以安全领域为例,亚马逊云科技每天要处理超过1万亿次DNS请求,并且每天都会自动发现12.4多万个恶意域名——这是人工系统无法复制的自动化过程。因此,我们不应该问“我们应该自动化什么?”,而应该问的是“我们还有哪些没有自动化?”我们应该将一切无需判断决策的事务都自动化。
例如,客户可以使用Amazon Bedrock Serverless Agentic工作流程,创建智能化的票据分级系统。在这些系统中,针对特定用例场景训练的自主AI代理可以自行解决问题,在必要时才升级给人工处理。自动化是应对复杂性、提高效率的重要手段。当我们将大量重复性工作交给机器去执行时,不仅能极大降低人工操作的复杂度和出错率,还可以让人类的注意力集中在真正需要判断和创造的环节上。
更进一步降低分布式系统复杂度
同时,Werner深入解读了Amazon Aurora DSQL背后的核心技术与逻辑,包括关键的繁简之道思路、从前端到存储的5级传输架构,以及打破了分布式系统时间无用论,微秒级时间精准同步的Amazon Time Sync Service。正是这一系列突破性的技术,为客户提供跨区域、强一致、低延迟的Amazon Aurora DSQL。
Werner说,时间可能是最根本的构建模块。亚马逊云科技的微秒级精准时钟和时间同步服务,将帮助客户显著降低复杂度。
CTO Fellowship
科技的力量是双刃剑,能造福世界,也可能带来不利影响。作为科技从业者,我们肩负着更大的社会责任。Werner呼吁,不要将科技孤立于社会之外,而是要主动以科技助力解决人类面临的种种挑战。“现在去构建”一个更美好的世界,正是科技人的终极使命!
[1]参考链接:https://docs.aws.amazon.com/wellarchitected/latest/reducing-scope-of-impact-with-cell-based-architecture/what-is-a-cell-based-architecture.html
© 版权声明
本文的所有权归原作者所有,未经授权禁止转载和复制。如您侵犯了您的权益,请及时联系我们,本站将立即删除。谢谢您的理解与支持。
相关文章
暂无评论...