理解Docker（三）：技术栈——一元到多元

【编者的话】Docker的另一个影响就是关于团队技术选择的，软件和互联网产品业务逐渐变得复杂，单一技术栈不再是最好的选择，Docker为多元化技术团队提供了帮助。

前面其实已经提到，设计和开发人员对基础设施的一个期望是不要限制自己的技术选型，这个需求比较新，因为这是一个趋势的产物——随着我们做的系统越来越复杂，系统间的协作越来越普遍，单一的技术栈有多元化的趋势。

以我熟悉的B/S结构下的应用系统开发（包括互联网应用）为例，最早的时候可以按照语言划分为三个技术栈：PHP主打网站开发，微软系主要结合Visual Studio提供快速应用开发，Java其实有些后来居上的味道，借助J2EE对准的是企业应用市场。在旧的EJB模型逐渐式微，Spring异军突起的年代，Java/J2EE也开始慢慢进入互联网领域，现在以阿里巴巴为首的一些电商就主要采用Java相关的技术栈。

从传统的J2EE到Hadoop，Java社区逐渐变得上下通吃，而PHP和.NET社区也是自成体系。

从2007年开始，Ruby on Rails逐渐被中国开发者社区所接受和追捧，它的卖点是简洁、研发效率高，这时，Ruby的优势主要体现在web开发和脚本运维上，一些人在进行复杂计算或者面对高并发场景的时候会考虑使用其它语言工具，比如Java和Erlang……技术栈开始多样化。

到了2011年后，Node.js又异军突起，它主要的卖点是事件驱动模式和异步编程，由于自身机制，Node.js的所有的库都有很好的并发能力，这是Ruby社区一直没有彻底解决的，所以一部分Ruby开发人员迁移到了Node.js，同时也有一些人开始接触更多的选择，比如Scala、Closure、Lua……技术栈越来越多。

经过这些变迁，至少在互联网领域，常用的技术栈已经不再纯粹，加上2007年开始c10k的影响变得普及，2012年大数据的流行，以及2013年的移动互联网的疯狂，服务端系统的复杂度在直线上升，现在已经很少有公司使用单一语言技术栈来解决问题，即使在淘宝，也会有各种小众语言和技术框架的使用问题。原有的、绑定在单一语言技术框架下的基础设施面对研发人员越来越多的挑战。

另一方面，越来越多的公司接受了敏捷的理念，所以也在不遗余力的推进敏捷社区的最佳实践，其中就有持续集成和持续交付，而后者的一个很重要的基础设施就是配置管理。这包括源码如何管理、打包/单元测试/集成测试如何进行、交付产物如何标准化、部署怎样自动化等等问题。

这些问题本身就已经很复杂，再叠加上技术栈的多元化趋势，这对研发体系是一个很大的负担，想要提供公共的服务设施就需要寻找一个最普遍的基础。

共性和个性永远是个矛盾，过于强调共性则会丢失个性，在服务器软件领域，Linux无疑是一个相对比较好的折衷，唯一的问题是Linux本身也有众多的distribution，各种工具不尽相同……这时我们看到，经过Docker“简化”的Linux能很好的处理这个问题。

与早期的PaaS比如GAE相比，Docker让用户使用的是一个真正的Linux环境，而且，Docker本身并不排斥各种distribution，在共性和个性的矛盾中，Docker把权力交给了用户，让用户来自己准备自己的技术基础设施。

这个思路很类似Chef/Puppet，自己掌握的环境自然具有最大的弹性和灵活性，方便用户发挥技术上的创新能力。不过Docker更进一步，它提供了image/container机制，借助AUFS/Overlayfs这样的技术，用户可以很简单的将某些基础设施固化，比如以小团队或者以语言/框架技术栈为单位建立基础镜像，然后各团队叠加自己的业务代码，这样做节约了时间，也就意味着可能将这种环境管理能力从线上扩展到线下，这是相对于Chef/Puppet更加先进的地方。

这个变化对整个研发领域是有影响的。

首先，借助这个能力，我们可以用合适的技术解决恰当的问题，而不再需要“手里拿着锤子，看什么都像钉子”。当然，过去我们也期望这么做，但是由于基础设施的缺位，我们要控制自己的技术构想，让步于架构的可行，现在约束少了很多，架构师将更有自由度。

其次，Docker的方案是“将环境交给开发者”，因此，开发人员需要懂linux，虽然不用当孔乙己，但是熟悉环境将不再是少数人的责任。

粗看起来这是开发人员的坏消息，其实不然，我们之前提到过，Docker实际上是对Linux的某种简化，这使得开发人员的学习成本降低了不少，以我的标准看，学习Docker时需要了解的东西，基本上也就是一名开发人员本就应该学会的东西了。

当然，上述说法并非人人同意，现实中确实也有这样的情况——业务场景的重要性非常重要，以至于我们不能在技术学习上占用太多的时间，开发人员需要先抓紧时间学习核心知识。这时，比较好的做法是借助Docker hub查找你使用的技术栈的环境，然后找到最为流行的镜像，用之即可——这背后更象是分工的体现。

最后但并非不重要的一点，是关于多元技术栈的协作方式。通过现实中的系统实践，我认识到应该尽量避免混合语言编程，不同的语言技术栈应当保持其独立性，然后进行进程间、系统间协作，用搭积木的方式来搭建系统，这是改进系统可维护性的重要一点。这意味着我们要尽可能的分拆原有的大而全的系统设计，而这种协作也需要有基础设施的支持。所幸Docker不是一个单一技术，它背后还有Compose、Swarm、Mesos等框架组织配合，帮助我们进行管理。

基于Docker这样的技术，我们就可以用通用的方式为不同技术栈提供配管、运维等基础设施，这条路指向的正是云，这也是现在 Container as a Service 变得越来越热的原因。

从一元到多元，技术栈的发明还将日新月异，但是我们很容易就可以将它装入Docker这个盒子中，借助服务发现和容器编制，我们可以让异构的技术彼此合作，发挥各自的优势。这正如人类发明了越来越多的商品和原材料，但还是统一使用集装箱，这样就可以用很低的成本互通有无，实现全球合作。
本文转自：http://dockone.io/article/359

未经允许不得转载：SRE空间 » 理解Docker（三）：技术栈——一元到多元