2015.5 技术雷达 | 技术篇

（点击图片可查看大图）

当多个独立开发的服务通过 API 交互的时候，API 提供端的改动会让它所有的消费端调用失败。消费端服务通常也不会直接去连接处于开发中的提供端服务来进行测试，因为这样的测试是缓慢且脆弱的（martinfowler.com/articles/ nonDeterminism.html#RemoteServices），因此最好的方式是采用测试替身（martinfowler.com/bliki/TestDouble. html），但这又引出了测试替身和实际的 API 之间失去同步的风险。消费端的开发团队可以通过使用集成的合约测试（martinfowler.com/bliki/IntegrationContractTest.html）来保护自己——其比较真实服务的响应和测试替身之间的一致性。这样的合约测试是非常有价值的，而更有价值的方式是消费端把它们的测试提供给 API 提供端——采用消费端驱动的合约（martinfowler.com/articles/consumerDrivenContracts.html），提供端可以运行所有消费端所提供的测试来验证自己的修改是不是有可能引起问题。这种消费者驱动的合约测试（consumer-driven context test）是成熟的微服务测试策略（martinfowler.com/articles/microservice-testing/）中非常核心的组成部分。

当我们需要一张描述当前系统的基础设施或物理架构的图形时候，我们通常会选用自己最喜欢的工具来绘制。但是当你使用云或者其他虚拟化技术的时候，这种方式却不再适用。我们可以使用这些平台本身提供 API 去查询实际的基础架构环境，并使用一些简单的工具比如 GraphViz（graphviz.org），一些可以输出 SVG 格式的工具，生成实时的，自动化的基础架构图（automated infrastructure diagram）。

离线优先 Web 应用程序（Offline first web applications）提供了基于缓存和更新机制来设计 Web 应用离线访问的能力。它的实现需要在 DOM 中设定一个标志来检查接入设备是否在线，离线则访问本地存储，在线则同步数据。现在所有的主流浏览器都支持离线模式，通过显示的指定 HTML 属性来使本地信息可访问，同时启动如 HTML， CSS，Javascript 或其他资源的下载和缓存。当前已经有一些工具使离线优先应用的实现变的简单，如 Hoodie（hood.ie），CouchDB（couchdb.apache.org），不仅如此它们还提供与本地部署的本地存储应用的集成能力。

大多数软件开发的心智模型都是做项目，在不同的档期内进行计划、执行和交付。敏捷开发极大的挑战了这种模型，通过与开发过程同时进行的持续需求发现，代替了预先的需求确定。精益创业的技术，如观察需求的 A/B 测试（martinfowler.com/bliki/ObservedRequirement.html），进一步削弱了这种心态。我们认为，大多数的软件开发工作应该遵循精益企业的引领（info.thoughtworks.com/lean-enterprise-book.html），将自己定义为构建支持业务流程的产品。这样的产品并没有所谓的最终交付，更多的是一个探索如何更好的支持和优化业务流程的过程，只要业务依然有价值就会不断持续下去。基于这些理由，我们提倡企业组织依照产品而不是项目（products rather than projects）的思路进行思考。

当前大多数开发团队都意识到编写安全软件并以负责任的方式处理用户数据的重要性。他们确实面临着陡峭的学习曲线和大量的潜在威胁，其范围从有组织的犯罪和政府的间谍活动到仅仅是为“玩笑或激怒什么人”而攻击系统的年轻人。威胁建模（Thread modeling）（owasp.org/index.php/ Category:Threat_Modeling）是一组技术，主要从防御的角度出发，帮助理解和识别潜在的威胁。当把用户故事变为“邪恶用户故事”时，这样的做法可给予团队一个可控且高效的方法使他们的系统更加安全。

Flux（facebook.github.io/flux）是 Facebook 为其互联网应用开发所采用的一种应用架构。它通常与 react.js 一同被提及，Flux 基于一个单向数据流，用户或外部事件对数据存储的修改会触发数据在渲染管道中向上流动。已经有好一阵子我们都没有看到任何古老的model-view-*架构的替代者了，Flux 拥抱这种 Javascript 前端应用与多个后端服务通信的现代互联网时代。

当前，大部分开发人员习惯使用 git 来管理源代码以及协作。但是，git 还可以为其他一些情况提供基础的实现机制，比如当人们需要使用基于文本化的文档进行协作的时候（这些文档可以被很容易的合并）。通过使用基于文本的可编辑格式，我们已经看到越来越多的项目把 git（git-scm.com）作为一个轻量化的 CMS 来使用。Git 有很多强大的功能，通过使用分布式的存储模型，Git 可以支持对变化的跟踪以及寻找替代品。然而，难于大范围采用 Git 的最大原因是 git 对于非编程开发人员来说并不容易学习，而我们期望看到更多的构建在 git 核心之上的工具的出现。这类工具可以为一些特殊听众简化他们的工作流程，如作为内容的作者。我们也欢迎更多的工具支持对比和合并非文本文档。

凤凰服务器（martinfowler.com/bliki/ PhoenixServer.html）的想法现在已经被很好的建立并且在被应用到一些正确的问题上时带来了很多好处。而我们要部署的服务器所依赖的环境，如在某些情况下需要等待网络配置、负载均衡、防火墙端口等等情况，却已逐渐成为修改配置时的主要瓶颈和限制。凤凰环境的概念可以帮助这种情况。它允许我们可以用自动化的方式创建整个环境并保证定期销毁和重建整个环境的流程正确，例如在AWS上使用CloudFormation。凤凰环境可以支持为测试，开发，UAT等等配置一个全新的环境。它也可以简化对灾难恢复环境的配置。由于凤凰服务器的模式并不总是可行的，我们需要小心地对待诸如状态和依赖，在蓝绿部署中用它对环境配置进行重置可以成为一种方式。

函数式反应型编程在过去的几年渐渐开始流行起来，同时这个概念越来越多被延伸到在分布式系统架构中。根据反应型编程宣言(reactivemanifesto.org)，反应型架构（reactive architectures）主要基于通过一个网络下独立进程间的单向，异步的不可变事件流（可能具体实现为微服务）。在正确设置下，基于这种架构的系统容易扩展，具有弹性，也会减小了各个独立处理单元间的耦合。但是完全基于异步消息传递的架构同时会引入相应的复杂度，并且常常会依赖于一些专有的框架。所以我们推荐在选择这种架构风格前首先了解自己系统对于性能以及可扩展性的需求。

对于安全，传统的方式依赖于前期的需求规格以及最后阶段的验证。这种“安全三明治”的方式很难应用于敏捷团队，因为大部分设计都贯穿于整个过程，而且也没有持续交付所提供的自动化便利。公司或者组织应着眼于如何在整个敏捷开发周期中注入安全实践。这包括：正确评估当前威胁模型的级别以做前期设计；考虑何时将安全问题划分为独立的故事、验收标准、或全局的非功能性需求；在构建流水线中引入静态或动态的自动化安全测试；考虑如何将更深层次的测试，如渗透测试，引入到持续交付的发布过程中。正如 DevOps 的出现使得过去相互博弈的团队能够重新合作一样，同样的事情也正发生在安全人员和开发人员身上。（尽管我们并不喜欢安全三明治模型，但这也比根本不考虑安全要好得多，糟糕的是，这依然是一种非常普遍的状况。）