不知不觉又一年了，还记得去年这个时候认识了师傅，听了微服务架构、领域驱动设计、测试驱动设计的解惑，以及自动化部署的应用，当时的感受真的是醍醐灌顶。
月底马上又要听到师傅在交流会上的演讲，很是激动。
感动和激动之余，这次也抱着另一个目的参加交流会，从架构转型为DevOps。
一年的提升
一年之间，微服务架构的思想和传统架构思想的融合并实践，只能说现实中的项目可比理论要艰难太多，服务器预算不够设计上的妥协，运维的能力有限，招不到运维，对运维人员的培训和妥协，在开发小组中上下贯彻敏捷，编码规范和代码审阅。
一年之间，团队开发环境和生产环境的自动化部署，现在的ZF项目真的难度比一般的互联网创业项目大太多太多，本来业务就相对复杂，而且各地区需求不一，加之近年来政策驱使各种区级、市级的数据互联互通，使得技术上被动去触摸天花板，而且相比创业项目还有历史技术包袱。
招投标甲方居然以容器化集群技术为参数，还好早有准备。
用户有各种大数据需求，原本我们的数据量也到了一个临界点，就是NoSQL、MQ该用上的都上了还是勉勉强强，但上Hadoop又觉得我们规模还不够，拼拼凑凑还能用，docker、k8s也是可上可不上的边缘。
关于容器化和自动化部署，仅在开发小组和开发测试服务器使用，的确帮助了我们不少。但要拿到生产环境，就受到了各方面的限制，比如公司组织结构、运维人员能力、客户的地区，无法做到像亚马逊提出的“谁开发谁运维”。
举个微服务架构落地的例子
开发团队中使用容器化自动化部署微服务，我们从中受益，也自认为达到了本市内同行技术的天花板。
由于网络原因，无法打通从开发环境直接发布到生产环境。
那么我们采用一种折中的办法，在生产环境搭建另外一套自动化部署，运维人员从开发手中拿到编译后的程序包，放入指定目录，点击“立刻构建”，然后等待自动发布的完成。
这已经是折中办法了，但现实会让你吐血到妥协，用户可能无法提供清一色linux服务器，还会提供windows服务器，打断你的一套部署方案。还没完呢，还会以服务器预算不够的理由让你们看着办，没办法咯，只好去掉注册中心，并且缩减负载的节点，好在这一切只要修改配置文件无需改业务代码。
你说docker容器化部署能解决开发环境和生产环境的差异是吗？用户提供的服务器硬件直接来个不支持虚拟化技术。
而且技术处于新旧交替时刻，旧的SOA中ESB+ETL的模式和新的微服务架构api-gateway安全验证+MQ并存，没办法呢，新换旧总也不是一蹴而就的事情，总得有个过渡吧。
一座座大山挡在前面，你得先去注册中心，然后去自动化部署，然后去容器化部署，最后到用户的环境里又回到了最初的样子。当用户的需求摆在那里，用户的期望摆在那里，已经未来政策的方向摆在那里，必须得让我们用最新的技术同时兼容最原始的搞法。
大数据
目前，也只是可能有大数据的需求，可以说是ZF的一种试探和尝试，一旦有一家公司或一个试点成为成功案例，那么在未来，这种需求将会变成一定的、必须的。
大数据，也许会成为我们的未来，但现在，我们要稳扎稳打，把大数据的前置技能给扎稳了。
前置技能：NoSQL，数据挖掘，实时分析，商业智能，全文检索，容器化，集群。