梁启鸿，现任广发证券信息技术部副总经理，热衷于运用互联网开源技术到证券业应用中、打造新型金融科技研发组织。加入广发证券前分别在雅虎研究院、Sun及Morgan Stanley等公司任职。
2016年，容器化技术如火如荼，诞生于2013年的Docker成了行业的宠儿。容器技术也已经在广发证券规模化使用。
容器技术虽然有点过火现象，虽然很多IT人（尤其是在传统垂直行业的信息技术部门）依然怀疑容器与虚拟机的差别，但总体来说，当今企业互联网+大潮，容器化算得上是软件开发领域的又一次“运动”。抱着开放的心态看，虽然Docker技术本身尚欠缺成熟，但是容器技术对未来的软件架构会产生重大影响，有可能成为传统企业IT拥抱互联网技术、升级架构体系的一个转型契机。
“软件开发”也遵循“合久必分”（Divide-and-conquer）、“分久必合”（Combine-and-conquer）的规律，例如：从Mainframe向Client-Server到Web/3-tiered架构的发展，可以算是一个分层分治的过程；Client-Server架构下的系统多了就造成服务器端资源的浪费，然后以IBM、Sun、HP为首的厂商，在本世纪初开始推销所谓Server Consolidation的解决方案。随着虚拟化技术的成熟，物理服务器逐渐变成虚拟服务器，世界又回归一个逻辑上分布、物理上集中的“超级Mainframe”。有些技术，往往是“似曾相识”，是新技术世代下用新技术手段对旧的理念的回归。例如SOA架构+RIA，是对C/S架构某种程度上的回归、虽然技术载体大不一样。同理，Micro Services也体现SOA的理念（虽然两者是巨大的不一样，见后文）。
容器化，可以说是近年来最重要的一次“运动“，很快就会成为一种潮流。无论有无必要，开发工程师的代码都以容器交付，否则就像Web 1.0时代还在开发Client-Server甚至Mainframe的应用，都不好意思出去跟人说。在这股潮流下，有厂商的推波助澜，有一窝蜂的赶潮流，也有切实的业务场景驱动。
无论如何，容器化将为软件业带来以下变化。（1）常态化，尤其是当ISV也把它们的产品容器化之后；（2）促进分布式架构在传统企业IT里的采用（此前，大部分垂直行业IT并不擅长互联网企业所擅长的分布式架构，现在只要接受了容器概念，显然就走向分布式）；（3）促进已经讲了8年以上的DevOps落地、可操作。
说到传统企业IT的技术架构，就不得不提一下“去IOE”，因为尤其在金融机构，IOE是无可辩驳的存在。
乍一听，“容器化可以帮助‘去IOE’”的说法有点哗众取宠。但仔细想想，其实还真可以拉扯点关系。
如果我们不带偏见的把IOE看成一些象征性的符号而不是具体的某些公司的话，IOE一定程度上代表了上一个世代的技术，对于只生存在开源技术世界里的互联网企业的年轻工程师尤其如此。IOE甚至在一定程度上是Client-Server架构思潮下的产物，代表了以关系型数据库为中心、以中央存储阵列为主导、以品牌服务器硬件为载体的技术架构风格，这类技术的存在依然有充分必要的业务应用场景，盲目的“去”，只能是自找麻烦和浪费资源。
但换一个角度看，“去IOE思维”却又是有意义的，因为在实践中我们已经发现：关系型数据库被企业里的应用开发者们过度滥用。事无大小，都被存入数据库，包括一些配置信息。事务型操作往往也没有控制好粒度，开发者为了“稳妥”起见囫囵吞枣的把CRUD操作都丢到事务里，期望由数据库来解决自己的不求甚解和懒惰。实际上，很多问题，其实是可以不用关系型数据库解决的。互联网时代尤其是Web 2.0开启后，从3-tiered向分布式架构演进，RDBMS为中心、高端硬件为依托的架构已经力不从心；就算不向互联网转型，传统业务系统在当今这个时代沿用旧的技术架构依然扛不住，比如，在2015年疯狂的股市下，高频、高并发、海量的交易就是股票交易系统的梦魇。
“去IOE”最难的是观念的改变，传统企业IT的工程师，非常习惯于用关系型数据库的语义、概念作为对业务领域（businessdomain）的建模工具，一言不合就开始设计表结构、画ER（EntityRelationship）图。开发过程中，可能大部分时间消耗在ORM（Object-Relationsal Mapping）上,即从数据模型出发封装一些对象以便于数据持久层和内存之间关联起来。这导致传统IT系统的升级动辄涉及数据库迁移，功能扩展通常导致表结构改变。
实际上用关系型数据库的理念对世界进行建模（modeling），具有很多局限性。一是无法对业务逻辑进行抽象，二是无法对业务数据进行封装。这样做的缺点，是所建立的模型无法低成本扩展、重构，以快速应对持续变化的业务场景，在当今这个“只有变化才是唯一的不变”，并且变化频率本身是指数级改变（《奇点临近》作者Ray Kurzweil所言）的世界，这样的设计导致的显然是一个变更成本非常高的“脆弱系统”，无法拥抱改变，应对黑天鹅（关于脆弱系统，见塔勒布《反脆弱》）。
“世界观决定方法论”，中医和西医对人体的建模差别，决定治病的方法截然不同。例如前者用经络、寒热、干湿、虚实、阴阳来描述病理，后者用细胞、基因、细菌、病毒来看待问题，导致同一个疾病的不同处理手段。有些问题用这种模型来看容易解决，有些问题则用另一种模型描述更有效。盲目的用关系型数据库看待一切，是很多问题的根源。
以关系型数据库为中心的应用，一般都是单体应用（monolithic），虽然它们可能也会融合一些分布式的技术元素，扩容、扩展、弹性伸缩、响应变更等等这些非功能性需求，依然是它们所难以满足的。在看到这类架构的问题后，技术界开始出现混合编程（polyglot programming）、混合存储（polyglotpersistence）和混合处理（polyglot processing，例如大数据里的zeta架构）的潮流，微服务（Micro Services）的架构风格与理念也逐渐形成。
微服务实施的具体问题在于，停留在“理念”、“最佳实践”层面的东西，很难在一般垂直行业的IT内部落地，因为面向业务的工程师们，关注点不在底层技术细节，无法投入资源去研究自己的平台，凡是能在垂直行业推广的技术，必须是具体有形的工具、API、框架。
容器技术作为看得见摸得着的、同时被运维人员和开发人员使用的工具链，对微服务的开发和运维，提供了巨大的推动力。虽然微服务本质上不依赖于容器，但是没有容器技术的支持，微服务在一般企业IT里的落地是不乐观的。
这就产生一个非常有趣的副作用：一旦技术人员习惯了容器化的观念，他们很可能不知不觉就走上了分布式架构的道路、潜移默化接受了微服务的思维，我们知道技术人员是很容易“心为物役”的，他们的抽象思考往往需要寄托在有型的工具上。例如Heroku的12-Factors（12律），总结了12项在云上开发分布式应用的最佳实践，可以看到，采用容器化的架构，很自然的就吻合这些实践。
总而言之，“去IOE”从它最开始的起源来看其实是去单体应用架构、去“数据库中心主义”，是分布式架构对传统企业技术套路的颠覆，而容器化一旦成为主流，分布式架构就会不知不觉中成为企业IT架构的主流。
容器化既然被说的这么玄乎，那么是不是就该一窝蜂地引入企业IT呢？个人认为，
如果企业环境并无特别适合“微服务化” 的应用，那么也并无采用容器技术的必要，即便是已经采用了SOA的技术架构与技术治理，千万别以为就顺理成章可以换一个时髦点的名字“微服务”。
一个微服务通常很可能是通过从现有服务fork（开分支）、clone（直接复制）、mutate（变种）出来，这很有可能违反软件工程中一个所谓DRY（Don't Repeat Yourself）的原则。我们已经习惯于认为，剪贴代码是糟糕的、粗暴复制功能不好的。然而，我们必须接受一个现实，粘贴代码、复制部署服务可能就是大部分以业务功能为终极目标、以快速上线为首要任务的普通工程师的本能，quick-n-dirty是任何团队绕不开的取舍。微服务，通过结合容器技术，一定程度上接受了普通程序员克隆服务、克隆代码的“陋习”。
比如，在系统升级方面，在条件允许的情况下，运维工程师最喜欢的可能是部署一套新的，旧的不碰。新的没问题，把旧的关闭；新的有问题，把旧的切换回来。微服务天然是考虑支持同一个服务的多个版本并存的，而容器则是实现“不可变基础设施”（Immutableinfrastructure）的最佳套路，它们两个一拍即合。对于快速敏捷支持不同的业务线、产品线，也许复制代码克隆服务是一个更高效的做法。
一位曾任职私募股权交易机构的架构师Michael Nygard，在他的“新常态”系列技术文章中，举了一个例子：他的公司有四十多个不同的交易席位（tradingdesk），分别在不同的市场采用不同的策略进行交易。每个交易席位都有自己的技术团队负责交易应用开发。如果他们像很多大企业一样采用一套单一的、集中式的交易系统，则任何交易组对系统的变更均会对其他组产生潜在的损害。因为变更影响他人、bug产生系统性风险、测试需要更繁复覆盖更充分、变更发布周期需要更长、升级需更复杂慎重、交易系统受影响面更，他把这些潜在能导致失败的影响称之为“失败域”（failure domain）。Michael的雇主选择让每个交易组独立维护自己的小型、单一、功能聚焦的交易应用，开发工程师和交易员坐在一起工作、小团队作战、快速迭代，以此来最大程度缩小各交易组被动关联产生的“失败域”。这个场景，对于从事证券交易系统开发的工程师，是非常熟悉的。在这里我们看到两个以下极端的取舍。
1. 交易系统从架构和基本功能的角度上看都是大同小异的，以一套理想的、大而全的、集中式的系统服务各条业务线、各个交易市场、各种交易产品，其好处也许是集中运维统一监控，服务归一、数据完备，消灭了信息孤岛，公司能获得跨市场、跨产品、跨业务线的最完整的经营数据，轻易实现合规监管、统一风控。但是这种中心化系统，本身的任何变更都是牵一发动全身，任何缺陷都导致公司级风险，是一个典型的“脆弱系统”，也不利于任何业务线的单独敏捷运作。
2. 类似上述私募股权公司的做法，完全去中心化，多套交易系统冗余建设，在一定规模的证券公司里，几十套交易系统是常见的，确实产生很多问题。例如一个合规要求或交易市场的新业务，必须在几十套系统里变更升级，硬件资源得不到充分的共享利用，不同交易系统往往是异构技术形成一个个竖井（Silo），信息孤岛的形成给统一风控统一经营造成巨大困难等。然而，这个去中心化的做法，却是符合“反脆弱”精神，它把失败域变小。每条业务线有自己的交易员、业务专家、工程师以及系统，响应市场竞争的效率最高。
微服务架构很可能对上述情形的解决是有帮助的。首先，在实际操作中，去中心化基本上是共识。避免全局、系统性风险比什么都重要，所以功能相同相似的服务在不同业务线、不同约束条件、不同目标用户环境下冗余部署是必须的；其次，越复杂、越大块头、越黑箱型的代码模块，越难弄明白，越怕被触碰，也就隐含越高风险，微服务化使之增加透明度；其三，一些服务例如交易引擎，架构大同小异但是细节很不一样，与其反复抽象、重构、支持一切交易市场、交易产品、资产类型，还不如克隆一下，把相互依赖以及对某些共同设施的依赖均降到最低，各自迭代发展，让每条业务线获得最不相互掣肘的、最高效率的技术支持。
在微服务架构的思维下，服务们通过克隆、变异、分叉而诞生，然后迭代发展、存活、消亡。这种架构，可以称之为进化式架构（evolutionary architecture）。进化式架构有一个有趣的作用，就是代码“去库存”。这里说的“代码库存”，不是指代码的技术载体，如Git、SVN等代码库，而是一家企业多年开发积累下来的代码。世界的变化总是快于软件的进化的，而积累了十年的几百万甚至几千万行代码，总体来说是很难对变更友好的。这个时候，代码库就变成了库存、技术债、阻碍业务创新的惯性。金融行业的应用系统，有很多这样的东西，庞大而沉重，日益成为厌恶害怕变更的“脆弱系统”，面对这样的技术库存，我们很无奈。
微服务架构风格之下，也许更符合草根习惯的开发平台终于有机会出现：高度碎片化，大家都在写小组件小程序，除个别关键服务外一般难以对整个系统产生坍塌风险，任何小程序可以被丢弃被重写等。当然，前提是我们指望容器编排技术结合监控技术和cloud-native的各种架构模式把服务底层的运行平台搞定，所以一个强的平台团队依然是需要的。当我们有非常好的工具如容器技术，以支持我们在短时间内快速开发出代码、极大程度释放生产力的时候，我们才敢于丢弃过时代码，让服务派生与进化、用完即扔。
微服务架构带来更多的碎片化，对架构设计、开发运维挑战更大，对开发者技能要求更高。例如需要掌握一系列Cloud-native patterns（原生云架构设计模式诸如throttling、circuit-breaker、bulkhead等等）。容器技术作为一种工具链和微服务载体，则在此时发生了很大的促进作用，甚至是微服务化实际落地的可行性的一个重大保障。
采用微服务类架构，也需要调整一些“传统”的观念，例如关系型数据的高度归一性（Normalization）、代码的可重用性（Re-usability）和系统的精益化（Lean），可能不再是无可辩驳的“美德”。事实上，随着大数据技术发展应运而生的NoSQL运动，一定程度可以说是对高度强调归一性的传统关系型数据库理论的“反动”。在微服务的思潮下，我们的服务首先是不共享任何东西（share nothing），每个服务可能都有自己的持久化存储（backing store），形成所谓的混合存储（polyglotpersistence）；其次，基于领域建模的开发（Domain Driven Development -DDD），对于实现微服务更加重要，以完整业务逻辑为中心，并解耦了对开发语言、数据存储技术等假设。
微服务、分布式架构是比单体架构更复杂的，技术团队需要掌握此前不需要的知识。例如上述的Cloud-native patterns、Heroku 12要素、Reactive技术风格与技术工具等。一个企业如果没有具备这些知识与能力的技术团队，都不应该去考虑做微服务。幸运的是，容器工具链的发展，也许正在成为这么一系列工具，会促进微服务在传统企业IT的落地。
正如写UNIX小工具的人需要直接了解操作系统，写微服务的人需要直接了解一点容器与容器编排、原生云架构模式。容器技术让开发者真正第一次介入云计算，此前基于虚拟机的云计算只对运维有意义，对开发者透明，但是，试问此前有多少开发工程师在自己的应用系统里调用过虚拟机的API，基于业务需求控制云计算资源？又有多少人在意自己的代码跑在物理机还是虚拟机里？
容器只是又一种开发工具而已。然而，鸟枪换炮不仅需要相应的新操作技能与观念，还需要与之相适应的组织结构，工具使用者之间的协作方式、运作流程、管理模式都需要作相应变更——从“二炮”变成“火箭军”。
从组织结构方面来讲，容器技术给IT部门带来的一个最大的好处就是促进开发、运维一体化的部门文化。过去，开发和运维是割裂的，两者使用的工具也是不同的。尤其是开发上的一个变更，可能会带来整个金融系统的“黑天鹅事件”。而容器化IT系统之后，开发和运维一体化，二者采用同一套工具，通过容器技术能够更快地部署IT系统，更方便地维护IT系统，系统变更也更加友好。可以说，容易技术的最大得益者是运维部门。
自从微服务开始流行的这两年来，网上越来越多架构师在讨论“康威定律”，这不是偶然现象，是大家不约而同意识到，服务的切分、模块的解偶、技术系统的最终形态，很大程度取决于开发者所在组织的交流沟通形态。
过去，单体架构应用开发的团队，很可能是这么一个silo团队：一到多个界面及交互设计师、几个前端开发（Web 1.0时代，是HTML及模板编写者; Client-server时代，是MFC、JFC/Swing甚至X/Motif开发者）、几个服务器端开发（EJB/JSP的、更古老一点是CORBA/IIOP或者DCOM的）、一两个数据库的DBA。这种团队虽然有多个角色对应多个技术层，但严格来说不算“跨职能”，因为他们基本上既不运营也不运维自己的应用，业务人员和运维人员并不在团队内。为什么称之为silo团队呢？因为多个这样的团队之间，信息不透明、不流动。
微服务架构下的组织结构，具有如下特点：
1 有Gartner所谓的“外架构”与“内架构”之分，内架构主要围绕微服务的标准化设计，例如每个服务必须是实现单一责任（singleresponsibility）、服务边界（scope）清晰、接口约定（contract）明确稳定。外架构主要是平台，聚焦于系统性解决基于内架构的微服务实例的注册发现、编排、资源伸缩、生命周期管理、监控、高可用等等，解决服务碎片化带来的各种共性问题。
2 平台团队负责平台的构建、优化、维护，持续整合新技术、持续向服务开发团队提供工具与公共设施便利，例如利用Kubernetes、Swarm或者Mesos之类的技术构建容器云，支持多租户，基于行业（例如金融业）特有环境与要求定制网络与安全解决方案，用符合自身企业环境的技术解决docker的网络问题，诸如此类。微服务团队则由业务专家和工程师组成，联合维护和保障一个服务的功能、有用性（没人用的服务就没有生命力）、运维，其中工程师很可能是全栈的、开发自运维的；虽然系统层面的高可用由平台团队支持，可是服务运行中的业务逻辑故障显然只有负责开发的人自己直接搞定。
3 平台团队主动向企业各业务线的团队布道、宣传自己的工具与平台，争取更多的租户。而微服务的团队，同样需要向其他部门、团队布道、宣讲自己的服务，找到更多的应用场景和使用方。最后，各业务线的应用开发项目，则是在产品开发过程中组合、集成各种服务（同时也可能提供自己的微服务）以服务终极客户。所以，这是一个服务型的、“人人为我、我为人人”的组织。衡量这些团队的表现也好办，看看平台团队争取了多少租户、微服务团队支持了多少应用。
结合容器技术，基于微服务架构的组织，都可以成为DevOps型组织，因为容器工具链也许是迄今为止真正让开发与运维共同使用的同一套工具，把开发、测试与运维工程师通过CI/CD串在了一条协作生产线上; 此前虽然有Puppet、Chef、其他所谓实现“infrastructureas code”的工具，实际上不同角色的工程师依然是没有标准化的工具分享的。别小看了共用一套工具的厉害之处，工具所附带的整套技术语言、概念、词汇表，往往成为工程师们交流沟通、描述问题的标准语言，否则他们往往是“鸡同鸭讲”，同一个词汇说的完全不是一回事。
掌握新技术新工具，需要传统企业IT的组织思维与时俱进，作相应调整、重构。否则，生产组织基因不对，无法有效使用科技生产工具。
在这个开发技术快速更迭的时代，只能通过构建有科技基因的、对技术友好的组织，让团队和新技术共同成长，保持精益的技术文化和理念，才能稍稍具备一点独角兽的特质：Swift（迅捷）、Nimble（灵巧）。
图文转自微信公众号ITValue
中国最大的技术高管实名社区，提供互联网时代最全面权威、也最前沿有趣的B2B市场信息解读。
点击【阅读原文】，进入ITValue社区，与CIO们一起脑力激荡！
