BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

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

| 作者 Daniel Bryant 关注 667 他的粉丝 ,译者 邵思华 关注 3 他的粉丝 发布于 2016年4月21日. 估计阅读时间: 12 分钟 | 都知道硅谷人工智能做的好,你知道 硅谷的运维技术 也值得参考吗?QCon上海带你探索其中的奥义

来自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对如何防止密码泄漏进行了深入的讲解,并表示:在用户认证过程中必须通过某些技术实现优秀的安全性保障,例如为密码添加saltpepper等干扰信息、密钥延伸(key strectching)以及多阶段认证(MFA)等等。而“基于能力的安全性”(Capability-based security),例如签名申请或活动令牌等对于用户的授权也十分有用。另外,诸如SELinux强制访问控制(Mandatory Access Control - MAC)实现同样能够改进系统的安全性,而且比起在项目后期再为MAC的实现投入精力,在项目的前期能够更简单地完成实现。

Strauss认为,对于敏感信息或个人可识别信息的处理可以委托给可信任的第三方,例如联合身份管理(federated identity)服务或支付网关,这有助于减少对安全风险的内部管理投入。保持“不可触碰的数据”策略也是一种有效的方式。此外,在服务中可使用“黑洞(Black Hole)API”等模式,使服务以不可撤消的方式输出数据,这样一来,即使该服务有朝一日受到攻击,也不可能找到该服务曾发送过的数据。在数据传输过程中以及终结点之处应当对数据采取保护措施,HashiCorp VaultSquare推出的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

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT