O’Reilly 软件架构大会第一天内容回顾

来自 ThoughtWorks 的软件架构师 Neal Ford 与来自 O’Reilly Media 的软件架构会议的议程主席 Rachel Roumeliotis 在大会的开场表示，软件架构师这一角色经常要进行各种复杂的决策，而这些决策将对组织的技术与业务领域带来长远的影响。同时，现代化软件工程牵涉到的主题也非常广泛，这就意味着软件架构师这一角色需要保持不断地学习与实践。

Jonas Bonér 是 Lightbend 的创始人兼 CTO，他主持了大会的开场演讲“ blah, blah… microservices…blah, blah ”。他在演讲中表示，他相信传统的架构与平台已经过时，一体性的架构往往倾向于完成过多的功能，而无法对业务领域进行非常有效地建模。虽然微服务中的“微”可能并不是一个最恰当的词语，但其隐含的单一职责（这一思想来自于受Unix 启发的SRP 哲学）概念确实是非常有价值的。开发者所设计的系统也应当保持“灵活性与可定位能力”以“拥抱网络”。由于所有基于微服务的应用事实上都会被部署为分布式系统，因此坚持“猜测、致歉及补偿”这种沟通与行动的迭代是一种非常有价值的模式。此外， Saga 模式体现出了非凡的价值，它能够正确地处理在实际应用中经常出现的最终一致性。

“微”服务可能并不是一个最恰当的名字，但其隐含的单一职责（这一思想来自于受 Unix 启发的 SRP 哲学）概念确实是非常有价值的。

随后，在 ThoughtWorks 担任 CTO 的 Rebecca Parsons 进行了一场题为“ the evolution of evolutionary architecture ”的演讲。Parsons 表示，软件开发行业在发展初期并没有很大的野心，因此一体性架构与基于 SQL 的数据存储系统能够满足当时的需求，但敏捷宣言的出现驱使软件组织将目光放得更远。设计模式、新的设计方式以及持续集成过程的出现，使架构师得以持续地进行“设计演变”，以满足软件项目不断变化的需求。Parsons 提醒听众，在设计演变过程中进行数据迁移始终是一项非常困难的任务，因为数据复杂度的增长与生产环境的运行总时间是相关的。面向服务架构（即经典的 SOA）是对构建可组合系统的第一次尝试，并且取得了良好的效果，而如今，微服务或许能够将这一概念提升至另一个层面。不过，大多数组织不会轻易地接受新的技术与思想，他们要求这些技术与思想能够举出“存在性证明”，才会认可这些技术“已为企业应用做好了准备”。

在设计的演变中，持续集成等实践的出现为软件开发提供了一张“安全网”。

在本日大会的首场分场会议中，来自 Pantheon Systems 的 CTO David Strauss 进行了一场名为“Death Star Security”的演讲，演讲所强调的概念在于对系统边界的巩固增强，否则将可能产生巨大的灾难。这场演讲针对的是具有较高水平的参会者，因此在演讲中只简单地涵盖了安全性的基础知识，例如 L2/L3 防火墙、 web 应用防火墙、 OWASP 十大安全隐患、对 DDoS 攻击的控制、以及尽快应用软件补丁及更新的理念。Strauss 对如何防止密码泄漏进行了深入的讲解，并表示：在用户认证过程中必须通过某些技术实现优秀的安全性保障，例如为密码添加 salt 和 pepper 等干扰信息、密钥延伸（key strectching）以及多阶段认证（MFA）等等。而“基于能力的安全性”（Capability-based security），例如签名申请或活动令牌等对于用户的授权也十分有用。另外，诸如 SELinux 等强制访问控制（Mandatory Access Control － MAC）实现同样能够改进系统的安全性，而且比起在项目后期再为MAC 的实现投入精力，在项目的前期能够更简单地完成实现。

Strauss 认为，对于敏感信息或个人可识别信息的处理可以委托给可信任的第三方，例如联合身份管理（federated identity）服务或支付网关，这有助于减少对安全风险的内部管理投入。保持“不可触碰的数据”策略也是一种有效的方式。此外，在服务中可使用“黑洞（Black Hole）API”等模式，使服务以不可撤消的方式输出数据，这样一来，即使该服务有朝一日受到攻击，也不可能找到该服务曾发送过的数据。在数据传输过程中以及终结点之处应当对数据采取保护措施， HashiCorp Vault 或 Square 推出的 Keywhiz 等工具可实现各种优秀实践，例如安全的密钥管理，以及密钥旋转（key rotation）等等。Strauss 同时警告说，“模糊即安全”（security by obscurity）绝非一种有效的途径，组织应当通过“白帽子”风格的黑客活动实践以确定系统的安全性。

Mike Amundsen 是 API Academy 组织 API 架构部门的总监，他为听众带来了一场名为“ Twelve Patterns for Hypermedia Architecture ”的演讲。Amundsen 在演讲的开场部分表示，超媒体（hypermedia）只是一种概念，而不是一个具体的产品，它在本质上可以说是万维网的语言。人类通常是通过信息进行沟通的，而超媒体通过语义元素与对其他实体的链接提供了高效的通信方式。Amundsen 在演讲中引用了Christopher Alexander 的经典著作《建筑的永恒之道》（The Timeless Way of Building）以及GoF 的《设计模式》，他建议超媒体与API 系统的开发者可以将这些模式同样应用到消息的设计中。

本次演讲中提到了一些通用的设计模式，包括：“传递消息，而不是对象”，因为对模型的共享会造成服务间的耦合；“共享词汇表，而不是模型”，这是因为通过表现形式与关联，更易于使对象实现标准化；通过“使用表现器”对消息进行解释（例如通过使用策略模式以决定在两个服务之间使用何种 content-type 进行通信）；以及“发布 profile”，即通过一种统一语言对API 进行描述，使人类与机器都能够理解这种语言。

Amundsen 接下来为听众展示了几个“基本原则模式”，包括“必须忽略”，即创建具有耐受性的读服务，使其具备向前与向后兼容性，并遵循 Postel 定律；而“必须向前传递”是指不要为了下游的服务而对内容进行编辑；“提供 MRU”是指在超媒体中包含最近执行的行为与文档的连接；而“实现幂等性”则强调了将行为设计为幂等（即一个行为可以多次调用，所产生的效果与一次调用相同）的意义。Amundsen 随后又介绍了几个“共享协议模式”，包括：“使用相关性”，即返回相关链接，以帮助客户端进行导航；“使用导航”，为人类或机器提供一种对过程 / 流程进行导航的方法；“部分提交”，即允许对数据进行增量式的提交；以及“状态观察”，即提供充分的状态，使机器的行为实现自治性、设定他们的目标、并采取相应的行动。

在随后的一场演讲中，来自 Cognitect 的 VP Michael Nygard 对“无最终状态的架构”的概念进行了探讨。在演讲的开场部分，Nygard 指出：许多组织总是想寻求一种完美的“稳定状态”的架构，并尝试通过一系列（通常是欠缺考虑的）变更周期实现这一架构。这一流程被简化后就变成了：确定当前状态、设定最终状态，并提出计划（“往往表现为一个三年规划”）。Nygard 认为，大多数组织处理的都是复杂的系统，事实上，“这种稳定状态是持续变更的叠加效果”。为了开发一个能够高效演变的架构（以及支撑该架构的流程），Nygard 提出了 8 条规则。

1. 拥抱多系统 —— 组织中的数据通常都来自于多个不同的数据存储系统，这些系统表现了组织业务的多个领域
2. 将下游应用置于适当的上下文中 —— 将所有系统都需要了解的实体数量降至最低
3. 注意粒度 —— 不要创建权威式的数据模型（即为多个系统复用的统一模型）
4. 去集中化 —— 集中化的小组应定义适当的约束，不要轻易地将设计强加给其他团队
5. 隔离故障领域 —— 模块化可带来巨大的经济价值，在产生故障时，应对涟漪效应进行限制
6. 数据的存在应比应用更长久
7. 应用的存在应比供应商的集成更长久 —— 在集成点之间创建适当的“防护层”，并研究使用多边形架构（亦称为“端口和适配器架构”），以将系统的耦合降至最低
8. 提升可见性 —— 让你的工作可为人所见（通过内部博客或 wiki 等手段），并建立一个内部的开源文化

在演讲的总结部分，Nygard 介绍了在基层建立“工程师文化”的益处。他表示：架构师无法对将来进行预测，因为组织、业务以及市场都是不断变化的。因此，我们应当停止定义架构的“最终状态”这种做法。

在本日的最后一场演讲中，来自 GitHub 基础设施部门的高级总监 Sam Lambert 所做的报告题为“Leading Simplicity”。Lambert 讲述了 GitHub 技术平台过去几年来的演变历程，以及如何在各种新兴的、相互竞争的技术中选择稳定且得到认可的技术的过程。GitHub 平台的主体是一个基于 Ruby-on-Rails 的一体化应用，每天可进行多次部署。GitHub 团队推崇“远程工作优先”的工作模式，他们的工程师遍布全球。整个团队通过 IM、电子邮件以及视频电话进行沟通。组织的技术领导价值观体现在几个方面：在代码和工具方面应用了受 Unix 启发的单一职责原则；对新技术进行常规性的尝试，但在创新方面需要进行明智地决策；以及简单性：

为系统增加复杂性非常简单，而移除它却很困难……

Lambert 所论述的其他价值观包括：选择实用主义与可预见性，这也是为什么 GitHub 会选择将大部分数据保存在已经过实际应用证明其价值的 MySQL 数据库中；通过相互评审与讨论的方式避免创建复杂的系统，因为“优雅是应对复杂问题的解决方案”；以及稳定的重要性，因为客户需要 GitHub 能够保持始终可用。

如果读者希望了解这次在纽约举办的O’Reilly 软件架构大会的更多细节，请访问大会的官方网站。 O’Reilly 软件架构大会在今年还会举办多次活动，包括于 10 月 18 日至 21 在伦敦举行的活动（申请讲师的最后截止日期是5 月2 日），以及于11 月13 日至16 日在旧金山举行的活动（申请讲师的最后截止日期6 月1 日），有意者可访问演讲内容提议的网络以提交申请。

查看英文原文： Lessons Learned at the O’Reilly Software Architecture Conference: Day One