技术雷达：关于技术趋势的分析报告

| 2016-01-30

就在刚刚过去的 2015 年 11 月份，ThoughtWorks 又发布了最新一版的技术雷达。技术雷达是什么，来源以及如何运用，可以参考 Neal Ford 的一篇文章《Build Your Own Technology Radar》【中文翻译】，这里就不再赘述。在本期的技术雷达中，提出了四个最新的技术动态，分别为：“Docker 引爆容器生态系统”、“微服务及相关工具受到追捧”、“JavaScript 工具正在趋于平稳”、“安全是每一个人的问题”。本文就主要围绕这四个最新的技术动态，阐述一下笔者个人的理解和分析。

Docker 引爆容器生态系统

Docker 现在非常火，作为一个开源的应用容器引擎，它的出现让容器技术的使用和管理变得非常简单，也促使更多的人开始关注和意识到容器技术的真正价值和威力。由于其基于 LXC 的轻量级虚拟化技术，相比于 KVM 之类传统的虚拟机技术最明显的特点就是启动快，资源利用率高。启动一个容器只需要几秒钟，在一台普通的 PC 上甚至可以启动成百上千的容器，这都是传统虚拟机技术很难做到的。目前容器技术已经被广泛应用在软件开发的各个阶段各个领域，例如用于管理开发环境、用于测试、构建项目和实施持续集成，当然也可以作为传统云平台虚拟化的替代方案，实现更为轻量更具弹性的云计算平台。

虽然上文提到的这些应用场景都是非常有价值的，但还不能体现 Docker 或是说容器技术如此火爆的原因。我们知道 Container 通常翻译为容器，但是还有另一个翻译就是集装箱，集装箱被很多人称为是 21 世纪最伟大的发明之一，它的发明和广泛使用甚至改变了世界的货物运输体系，促进了经济的全球化发展，《集装箱改变世界》这本书就是讲述了集装箱是如何改变世界的。而我们现在所提的容器技术和 Docker，是不是也在致力于改变软件的世界，改变我们开发、测试、构建、部署、运维所有这些的现有方式呢？我觉得是有可能的，因为无论是集装箱还是容器技术都为我们带来了两个重要的好处：一致性和隔离。

屏幕快照 2015-12-05 下午 9.27.22

我们知道一个产品是否可以正常提供服务，只去确保软件本身没有问题是远远不够的，需要同时保证软件、基础设施（例如硬件、操作系统和运行环境）以及配置的正确性和可靠性。而传统的软件开发方式，对于这三个方面的管理是分离的，再加上三者之间错综复杂的关系，就造成了我们常常挂在嘴边的“环境问题”。但是通过使用容器技术，我们如果将软件、基础设施和配置作为一个整体使用容器进行封装，产生一个个已经同时包含了软件以及其运行环境的经过严格测试检验的“包”。这样当部署“包”的时候就不需要再考虑环境的问题，也不需要关心现在部署的是一个 Web 服务还是一个数据库服务，要做的只是把一个个容器标准化地安装到指定的容器引擎即可。

屏幕快照 2015-12-05 下午 9.26.07

可能正是大家都看到了容器技术以及 Docker 对于软件开发各个领域正在带来的改变，容器技术的生态系统也在经历着一个快速发展的阶段，涉及到开发辅助、集群管理、服务编排、内容发现、云平台搭建等各种工具框架都一一呈现在我们面前，其中像 Google 和 Amazon 这样的巨头也都在第一时间发布了各自与容器相关的服务和框架。

1224-王健-3

微服务及相关工具受到追捧

如果大家关注 Docker，也肯定会经常听到一种与之相关的架构，也就是微服务架构：

“微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通（通常是基于 HTTP 协议的 RESTful API）。每个服务都围绕着具体业务进行构建，并且能够被独立的部署到生产环境、类生产环境等。另外，应当尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建。”

这是 Martin Fowler 给出的对于微服务架构的定义，其中提到了微服务架构的四个特点：

将单一的应用程序划分成一组小的服务
每个服务运行在其独立的进程中
轻量级的通信机制
独立的部署到生产环境

我看过很多非常成功的公司在分享其系统架构演进历程时，往往最后都会落脚于服务拆分和业务服务化。其实这也不算是什么新的概念了，几年前流行的 SOA 面向服务架构就已经为我们描绘了一个服务化架构的美好前景。那为什么又提出了一种新的微服务架构呢？对于这个问题 Martin Fowler 在他的那篇《Microservices》也给出了他的回答。简要来说就是虽然这两种技术都是以服务化和组件化为目标，但是架构理念和技术策略上有太多的不同。例如上边提到的微服务架构的主要特点以及其倡导的演进式架构设计，去中心化的架构风格，采用轻量化通信机制，强调独立部署等都是与 SOA 所提倡的技术和思路有很大区别。微服务架构也更契合现代的技术发展趋势，例如 RESTful API 的流行，嵌入式应用服务器的应用，持续集成、持续交付的普及，容器技术爆发，组件化的趋势，云平台的发展等。

在引入微服务架构前，系统往往是以一个大的单体应用的形式存在的。此时任何功能的修改都需要重新构建部署整个应用，并且当需要水平扩展时也只能通过扩展整个应用的方式进行，无法做更细粒度的调度和控制。而当切换成微服务架构后，单一功能的修改只需要重新构建部署相应地服务即可，其他服务并不会受到影响。如果某个服务需要水平扩展时，我们也只需要扩展此服务即可。由此可见，微服务架构相比于传统的单体应用架构，可以极大的提高我们的资源利用效率和系统弹性。再加上通过服务化我们可以更容易的以组件的方式组合和重用现有服务，快速地构建出新的服务，使企业和产品更具竞争力。

1224-王健-4

微服务架构还有很多其他的好处：例如我们可以为不同的服务使用异构的技术架构，用最适合的技术解决最适合的业务问题（例如在某些服务中使用关系型数据库，而在某些服务中使用 NoSQL 数据库）；相对于单体应用因为每个服务都更小更简单，所以维护难度和成本也会比传统的大的单体应用要低得多；还有根据康威定律，这种新的服务架构甚至会改变我们软件开发的组织方式向小而精的多功能自组织团队和全栈式演进，前段、后端、运维、DBA 这种角色划分方式也许也会因此而成为历史。

微服务架构之所以经常会和容器技术一起被提及，是因为容器技术为微服务架构提供了一个非常匹配的基础设施，从而可以将这种架构的威力最大化的激发出来。设想一下，假如我们有一个产品采用微服务架构，并将每类服务及其运行环境打包为容器，部署于像 AWS ECS 这类弹性容器服务里。就可以实现通过实时监控每类服务的负载情况，通过自动化的方式快速按需对每类服务基于容器技术进行快速高效的水平扩展或是撤销，这样我们的架构就是一个高度自动化、高弹性、高资源利用率的应用架构，相比于传统的单体应用也将具备很大的竞争优势。

有得必有失，微服务架构有着这么多的好处，但同样也会引入一些新问题，最直接的就是分布式本身所引入的复杂性。例如如何保证服务间的契约，如何快速开发服务，如何保证轻量级通讯协议的可靠性等等。对于这些问题也有着相对应的解决方案，本期雷达就推荐了很多的工具和技术来辅助进行微服务架构下的软件开发。

1224-王健-5

JavaScript 工具正在趋于平稳

如果大家关注往期的技术雷达，肯定可以感受到 JavaScript 的火爆程度。例如在 2014 年 1 月刊就提出了“JavaScript 战车一往无前”，以及在 2014 年 7 月刊又提出了“JavaScript 大爆发，框架遍地开花，创新目不暇接”的最新动态。JavaScript 如今继续保持着它强劲的势头，但是我们也能感觉到无论是社区还是我们自己团队，大家在经历过暴风雨的波澜后，慢慢平静下来，无论对于 JavaScript 的框架、工具还是一些最佳实践上的认同也在慢慢的趋于一致。

1224-王健-6

ECMAScript 2015 目前在雷达上已经被列入了“采用”的阶段。意味着已经没有什么障碍和疑虑再阻止我们使用这个最新的规范，在 JavaScript 平台上享受一个现代语言为我们带来的简洁、便利和强大。在构建工具和包管理工具的选择上，NPM 和 Webpack 也逐渐成为越来越多人选择的对象。

而对于前端框架的选择上，React.js 热的发烫，它喊着“Rethinking Best Practices”的口号，举着组件化的大旗，让每个人目瞪口呆之后，又开始重新审视我们的前端开发实践。如果说容器化实现了基础设施的组件化，而微服务架构提供了架构层面的组件化方案，那 ReactJS 就把组件化带到了前端开发……哦对了，还有移动开发领域。

1224-王健-7

安全是每一个人的问题

安全越来越受到大家的重视，从“SSL 心脏滴血”到“Xcode Ghost”，再到时常出现的用户（商业）隐私信息泄露，钓鱼诈骗，恶性攻击等安全事件。让我们越来越切身地感受到安全对于企业和个人的重要性。并且随着互联网和软件行业的高速发展，安全形势也变得越来越严峻：从硬件安全到操作系统安全，从工具安全到依赖组件的安全，从网络安全到应用安全，从代码安全到密码安全。任何一个点的疏忽都可能为企业和个人带来毁灭性的打击和伤害。

与安全形势变得越来越严峻形成鲜明对比的就是以往我们在产品设计和开发过程中对于安全无论是在意识上还是在使用的技术上都远远达不到要求。对于安全的关注更多的是以一种“看门人”的方式进行的，也就是在开发和设计过程中往往很少考虑安全的问题，仅仅靠上线前的一段很短的时间，通过一些工具扫描安全漏洞，然后集中修复的方式。这种方式往往让团队处于非常被动的处境，很容易遗漏安全问题，产生安全风险，或是根本没有时间修复所有的安全问题就草率冒险上线。

而现在有越来越多的团队将安全引入到开发的整个生命周期当中，作为一等公民来看待和重视，将安全作为软件质量的一个重要组成部分。例如在软件的早期就通过引入威胁建模（Threat Modeling）的方式为产品做整体的安全建模，并将建模成果以验收说明的方式写入用例文档或是用户故事中。而开发人员也会在实现每个功能时将对安全的关注作为设计和实现的一部分，并为安全编写相关的自动化测试，纳入持续集成系统中保持对于安全的持续验证和关注。

1224-王健-8