成功者总是不约而同的配合着时代的需要，技术方案亦是如此。
我所在的公司已经运行六年了，期间经历了波峰成就了当时的社会现象，也经历了波谷，现在正处在平稳上升期。公司是团购网平台模式，技术上经历了三次大的重构，库表也都拆分完毕，前端是js+php，接口层是java系，数据库是MHA。前端做了静态化并分发到多家CDN，接口层面做了无状态化并且用负载均衡做了集群，后端有DMP数据库管理平台为MHA护航。基础设施监控层面做了zabbix监控和nagios报警联动，应用层面做了kafka日志收集和nagios报警联动，整体架构基本趋于完善。
但随着时间的推移，硬件发展迅猛，新采购的服务器按照原有的方式部署就会有大量的浪费，所以我们考虑更大程度的复用服务器。以前的复用方式是http级别的，基于虚拟主机方式。此方式有一个弊端就是发布一个虚拟站点，整个http服务要重启，而且在高访问量的情况下会出现服务重新加载慢的情况。解决此问题就需要隔离虚拟站点的服务，或者叫独立虚拟站点的服务。经过调研我们采用了docker容器化技术，成功的解决了隔离并且复用的问题。理论上在大批量docker化后，服务器会有大量空闲，所以我们要在做docker化的同时就考虑后续如何利用服务器。我们有两个方向：一是做私有云，为公司使用，乃至可以为集团使用；二是把空闲机器拆分，一部分完善docker在公司内的生态环境，另一部分用于做大数据分析。经过一系列的逻辑讨论，最终我们采用了第二个方向。下面略述逻辑讨论过程。
首先从实际角度考虑，当接口层面docker化完成后，撤下的机器是否够做云的。答案是由于机器过时严重，做云还需要采购关键节点机器，这样就会增加成本。其次docker化同时就必须要做docker生态环境的建设，比如发布,监控,负载均衡等等，这些都要和公司的实际情况相结合，不能只是照搬理论文档的范式。而这些生态服务就需要更多的机器，他们是服务于docker的。再次，公司是团购网平台模式，内部的BI部门是最能够技术变现的部门，所以我们应该加强他们的资源。
经过半年的调研与实施，现在有一小部分接口项目在线上使用docker，生态还没有完全建立，总之docker在我公司属于蓬勃发展期。
熟悉我的朋友们会疑惑，为何经过半年了只是几个项目在使用，并没有全面docker化。我给出的答复是：时代并没有迫切需要。回到卷首，我们看到“成功者总是不约而同的配合着时代的需要，技术方案亦是如此。”此时很多架构师会跳出来说，“注意，你危险了，你目光短浅了，你堕落了······”我给出如下回复：技术确实是配合时代需要而产生并且实施的，如果过度超前实施，只能带来反作用，很明显的就是成本上升和复杂度翻倍。一个成熟的架构师会目光如炬，适度超前实施，而且是明确实施的成果能够转化成为下一步的生产力的改造，在此前提下，牺牲一些复杂度和成本是可以理解的，但当公司内部的技术需求并没有发展到迫切需要或者将要迫切需要改造的时候，成熟的架构师一般会选择无为而治，更有甚者叫做无为不治。很明显，我上面的不做云做docker生态和大数据的方案也是出于适度的前瞻原则，并不是人云亦云，大家都做云了我们就要跟上时代做云，不做就如何如何了。说这样话的架构师永远不能带领公司实现利益最大化。
所以，在架构选型和架构实施的时候应该多思考，保持适度超前原则，否则就会事倍功半。还是那句话“成功者总是不约而同的配合着时代的需要，技术方案亦是如此。”
作者：李博谦
