就在刚刚过去的2015年11月份，ThoughtWorks又发布了最新一版的技术雷达。技术雷达是什么，来源以及如何运用，可以参考Neal Ford的一篇文章《Build Your Own Technology Radar》【中文翻译】，这里就不再赘述。在本期的技术雷达中，提出了四个最新的技术动态，分别为：“Docker引爆容器生态系统”、“微服务及相关工具受到追捧”、“JavaScript工具正在趋于平稳”、“安全是每一个人的问题”。本文就主要围绕这四个最新的技术动态，阐述一下笔者个人的理解和分析。
Docker引爆容器生态系统
Docker现在非常火，作为一个开源的应用容器引擎，它的出现让容器技术的使用和管理变得非常简单，也促使更多的人开始关注和意识到容器技术的真正价值和威力。由于其基于LXC的轻量级虚拟化技术，相比于KVM之类传统的虚拟机技术最明显的特点就是启动快，资源利用率高。启动一个容器只需要几秒钟，在一台普通的PC上甚至可以启动成百上千的容器，这都是传统虚拟机技术很难做到的。目前容器技术已经被广泛应用在软件开发的各个阶段各个领域，例如用于管理开发环境、用于测试、构建项目和实施持续集成，当然也可以作为传统云平台虚拟化的替代方案，实现更为轻量更具弹性的云计算平台。
我们知道一个产品是否可以正常提供服务，只去确保软件本身没有问题是远远不够的，需要同时保证软件、基础设施（例如硬件、操作系统和运行环境）以及配置的正确性和可靠性。而传统的软件开发方式，对于这三个方面的管理是分离的，再加上三者之间错综复杂的关系，就造成了我们常常挂在嘴边的“环境问题”。但是通过使用容器技术，我们如果将软件、基础设施和配置作为一个整体使用容器进行封装，产生一个个已经同时包含了软件以及其运行环境的经过严格测试检验的“包”。这样当部署“包”的时候就不需要再考虑环境的问题，也不需要关心现在部署的是一个Web服务还是一个数据库服务，要做的只是把一个个容器标准化地安装到指定的容器引擎即可。
可能正是大家都看到了容器技术以及Docker对于软件开发各个领域正在带来的改变，容器技术的生态系统也在经历着一个快速发展的阶段，涉及到开发辅助、集群管理、服务编排、内容发现、云平台搭建等各种工具框架都一一呈现在我们面前，其中像Google和Amazon这样的巨头也都在第一时间发布了各自与容器相关的服务和框架。
微服务及相关工具受到追捧
如果大家关注Docker，也肯定会经常听到一种与之相关的架构，也就是微服务架构：
“微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通（通常是基于HTTP协议的RESTful API）。每个服务都围绕着具体业务进行构建，并且能够被独立的部署到生产环境、类生产环境等。另外，应当尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建。”
这是Martin Fowler给出的对于微服务架构的定义，其中提到了微服务架构的四个特点：
- 将单一的应用程序划分成一组小的服务
- 每个服务运行在其独立的进程中
- 轻量级的通信机制
- 独立的部署到生产环境
我看过很多非常成功的公司在分享其系统架构演进历程时，往往最后都会落脚于服务拆分和业务服务化。其实这也不算是什么新的概念了，几年前流行的SOA面向服务架构就已经为我们描绘了一个服务化架构的美好前景。那为什么又提出了一种新的微服务架构呢？对于这个问题Martin Fowler在他的那篇《Microservices》也给出了他的回答。简要来说就是虽然这两种技术都是以服务化和组件化为目标，但是架构理念和技术策略上有太多的不同。例如上边提到的微服务架构的主要特点以及其倡导的演进式架构设计，去中心化的架构风格，采用轻量化通信机制，强调独立部署等都是与SOA所提倡的技术和思路有很大区别。微服务架构也更契合现代的技术发展趋势，例如RESTful API的流行，嵌入式应用服务器的应用，持续集成、持续交付的普及，容器技术爆发，组件化的趋势，云平台的发展等。
在引入微服务架构前，系统往往是以一个大的单体应用的形式存在的。此时任何功能的修改都需要重新构建部署整个应用，并且当需要水平扩展时也只能通过扩展整个应用的方式进行，无法做更细粒度的调度和控制。而当切换成微服务架构后，单一功能的修改只需要重新构建部署相应地服务即可，其他服务并不会受到影响。如果某个服务需要水平扩展时，我们也只需要扩展此服务即可。由此可见，微服务架构相比于传统的单体应用架构，可以极大的提高我们的资源利用效率和系统弹性。再加上通过服务化我们可以更容易的以组件的方式组合和重用现有服务，快速地构建出新的服务，使企业和产品更具竞争力。
微服务架构还有很多其他的好处：例如我们可以为不同的服务使用异构的技术架构，用最适合的技术解决最适合的业务问题（例如在某些服务中使用关系型数据库，而在某些服务中使用NoSQL数据库）；相对于单体应用因为每个服务都更小更简单，所以维护难度和成本也会比传统的大的单体应用要低得多；还有根据康威定律，这种新的服务架构甚至会改变我们软件开发的组织方式向小而精的多功能自组织团队和全栈式演进，前段、后端、运维、DBA这种角色划分方式也许也会因此而成为历史。
微服务架构之所以经常会和容器技术一起被提及，是因为容器技术为微服务架构提供了一个非常匹配的基础设施，从而可以将这种架构的威力最大化的激发出来。设想一下，假如我们有一个产品采用微服务架构，并将每类服务及其运行环境打包为容器，部署于像AWS ECS这类弹性容器服务里。就可以实现通过实时监控每类服务的负载情况，通过自动化的方式快速按需对每类服务基于容器技术进行快速高效的水平扩展或是撤销，这样我们的架构就是一个高度自动化、高弹性、高资源利用率的应用架构，相比于传统的单体应用也将具备很大的竞争优势。
有得必有失，微服务架构有着这么多的好处，但同样也会引入一些新问题，最直接的就是分布式本身所引入的复杂性。例如如何保证服务间的契约，如何快速开发服务，如何保证轻量级通讯协议的可靠性等等。对于这些问题也有着相对应的解决方案，本期雷达就推荐了很多的工具和技术来辅助进行微服务架构下的软件开发。