奇谈怪论:从容器想到去IOE、去库存和独角兽

聚众培训视频 浏览次数: 2016-11-30 23:13

2016年,容器化技术如火如荼,诞生于2013年的Docker成了行业的宠儿,它让炒了8年的DevOps有了更具体可落地可执行的工具。虽然有一定程度的过火现象('...

2016年,容器化技术如火如荼,诞生于2013年的Docker成了行业的宠儿,它让炒了8年的DevOps有了更具体可落地可执行的工具。虽然有一定程度的过火现象(所谓的hype),虽然有很多IT人(尤其是在传统垂直行业的信息技术部里)依然怀疑容器与虚拟机的差别,但总体来说,容器化可能算的上是软件开发领域的又一次“运动”。

每一次“运动”,都是有很多人追随、有很多技术架构被(一窝蜂的)重新设计、有很多系统被迁移,形成一种潮流(好像不那么干就被时代抛弃),代码的开发调试、架构设计和交付部署的方式发生巨大变化:

Mainframe:大型机、大集中、傻终端(dumb Terminal)。

2层架构Client-server和4GL:整个90年代 - 中小型机/x86服务器、工作站/PC终端。Mainframe应用很多被采用C/S架构重写。一时间都是DCE RPC、DCOM、CORBA-IIOP。

3层架构通行:Web 1.0时代开始到现在,浏览器、中间件、关系型数据库服务器的架构依然在很多企业中通行。C/S架构应用很多被迁移至三层架构。Struts+Spring+Hibernate(传说中的SSH)成为这一时代的web应用标配,JEE应用服务器曾经是“State of the art” 的技术,甚至成就了上市公司(例如WebLogic)。

SOA + RIA:SOA最开始是互联网技术(例如HTTP、XML等等)生态回归企业IT,新的技术载体实现企业应用所需要的RPC语义、服务注册与发现机制,再结合Flash、AJAX技术实现的富客户端(Rich Client),实现企业类应用所需要的、比一般网站类应用交互复杂的交互。

在CAP定律制约下的分布式架构:Web 2.0时代产物,participation age 的社交网络、UGC,海量数据海量流量促成。

容器化的分布式架构:为什么这算的上一次里程碑式的运动?因为它可能导致ISV的软件产品(例如MongoDB、Redis等)被容器化、导致行业解决方案容器化(例如交易系统)、甚至导致操作系统容器化(例如RancherOS和其他“极简主义”下支持运行容器服务的操作系统),它促进DevOps工具链的发展,它和CI/CD深度整合,它直接影响开发人员的思考方式。

Serverless架构:类似Amazon lambda、Google Compute Engine等,对于应用开发者而言交付方式部署方式都是有变化的,能否称的上“运动”,有待商榷,姑妄列出。

未知的运动与变革:技术的进步与变化,是加速度的,并且这个加速度本身的变化,也是指数级的,这是“奇点临近”作者库兹威尔(Kurzweil)的观点。总之,新的变革一定会来,快到你还没学会容器,新技术的“飞饼”已经摔到脸上。

其实,“软件开发”这个世界,依稀也是遵循“合久必分”(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” 本身是一个伪命题。企业IT降低对一些外国厂商和商业技术的依赖,固然从节省成本上有那么些好处,但如果不上升到 “民族产业”、“信息安全”的层面,减少几个数据库软件的license对于企业本身的效益是有限的,其伤筋动骨的技术迁移也许是得不偿失的。去了IOE,也没什么值得自豪 - 别高估了自己在国家信息安全方面的重要性,如果没有为业务经营、客户利益带来价值,恐怕只能是“然并卵”。

如果我们不带偏见的把IOE看成一些象征性的符号而不是具体的某些公司的话,IOE一定程度上代表了上一个世代的技术,对于只生存在开源技术世界里的互联网企业的年轻工程师尤其如此。IOE甚至在一定程度上是Client-Server架构思潮下的产物,代表了以关系型数据库为中心、以中央存储阵列为主导、以品牌服务器硬件为载体的技术架构风格,这类技术的存在依然有充分必要的业务应用场景,盲目的“去”,只能是自找麻烦和浪费资源。

但换一个角度看,“去IOE思维”却又是有意义的,因为在实践中我们已经发现:

关系型数据库被企业里的应用开发者们过度滥用。事无大小,都被存入数据库,包括一些配置信息。事务型操作往往也没有控制好粒度,开发者为了“稳妥”起见囫囵吞枣的把CRUD操作都丢到事务里,期望由数据库来解决自己的不求甚解和懒惰

很多问题,其实是可以不用关系型数据库解决的

互联网时代尤其是Web 2.0开启后,从3-tiered向分布式架构演进,RDBMS为中心、高端硬件为依托的架构已经力不从心

就算不搞互联网,传统业务系统在当今这个时代沿用旧的技术架构依然扛不住,2015年疯狂的股市下,高频、高并发、海量的交易就是股票交易系统的梦魇

“去IOE”其实最难的是观念的改变,传统企业IT的工程师,非常习惯于用关系型数据库的语义、概念作为对业务领域(business domain)的建模工具,一言不合就开始设计表结构、画ER(Entity Relationship)图。开发过程中,可能大部分时间消耗在ORM(Object-Relationsal Mapping)上 - 从数据模型出发封装一些对象以便于数据持久层和内存之间关联起来。这导致传统IT系统的升级动辄涉及数据库迁移,功能扩展通常导致表结构改变。实际上用关系型数据库的理念对世界进行建模(modeling),是有很多局限性的,一是无法对业务逻辑进行抽象,二是无法对业务数据进行封装。这样做的缺点,是所建立的模型无法低成本扩展、重构,以快速应对持续变化的业务场景,在当今这个“只有变化才是唯一的不变”并且变化频率本身是指数级改变(《奇点临近》作者Ray Kurzweil所言)的世界,这样的设计导致的显然是一个变更成本非常高的“脆弱系统”,无法拥抱改变应对黑天鹅(关于脆弱系统,见塔勒布《反脆弱》)。

 1 2 3 4 5 6 下一页 尾页
网友点评
猜你喜欢