离开应用场景谈技术那就是耍流氓，这也是为什么针对某个技术或者产品总会有多种截然不同的观点与看法。经常有朋友给我推送这样的文章，让我对孰是孰非发表看法。回答这种问题，我往往都会说大家都对，也都不对。朋友就会说我耍滑头，两边都不想得罪。实际上对于大多数冲突的观点，我用“也对也不对”这五个字去回答就正确得不能再正确了。凡事不绝对这句话在技术上基本上是到哪都说得通的。

前阵子有人在争论数据库是否应该放到容器里，大家说得都挺有道理的，因为大家都是从各自的应用场景和现状来谈的，所以正反双方的观点都很充分。确实有不少用户把数据库放到容器里，用Operator做自动化管理，日常的运维管理不需要了、备份也不需要了、数据库优化更不需要了，最后连DBA都不需要了。这些用户上了容器后用得很爽，不过也有不少用户在容器上碰得满头是包，数据库时不时出现卡顿甚至宕机，主从复制经常出问题，高可用切换也常常失效。这两种都是真实的场景和体验，都是事实，并不一定是哪个水平高用得好，其主要区别在于应用场景、系统规模与开发团队水平的差异。

与传统IT基础设施相比，云平台，容器化的IT基础设施在平台层面上的复杂度都是超级的，大多数使用者都无法完全掌握，甚至连有效的优化与管理都无法胜任。不过如果平台与上面的应用能够自洽，那么这些复杂性都是被屏蔽的，一切都是自动化的，无需人工干预的。这是企业IT梦寐以求的，大型互联网企业的成功实践就证明了这一点。让大型互联网企业能够玩转这种高度自治与弹性的软件定义数据中心的是互联网企业超乎寻常的技术能力，以及对自身业务的高质量把控，因此他们可以让应用系统与云平台高度融合，实现完全自治的闭环。

传统企业在这方面天然存在弱点，首先是业务规范性不好，企业IT对业务的理解也只是在摸索中，因此传统企业的系统研发是较为缺乏计划性的，因此业务系统与基础设施的匹配问题往往无人关注。再加上传统企业的管理制度把信息系统管理成一个个相互独立的烟囱。在业务系统没有打破烟囱的前提下，单单把IT基础设施的烟囱拆了，是完全不够的。

我见过一个企业的IT系统，他们目前强制系统上云，而且也确实把大量的应用系统改造上云了。目前应用都采用微服务架构，应用组件完全容器化部署，数据库也有一部分部署到K8S的容器中了。以前三四台物理机，十几个WEBLOGIC实例搞定的系统，现在分拆到部署在数百个POD中的微服务里了。因为微服务分拆得太细碎，而给这个项目分片的物理资源又有限，因此每个容器配置的资源都很紧张，经常会因为某个微服务的处理能力不足而导致应用出现卡顿现象。当我我问他们为什么不把微服务设置成动态伸缩的。他们说云平台给他们分配的资源是有限的，目前已经完全被他们占满，因此无法动态伸缩。问他们为什么不申请更多的资源，他们说目前云平台的资源十分紧张，除非某个系统的CPU总体使用率不超过某个阈值，云管那边无法给他们项目分配资源。如果因为让你的系统动态扩展而影响了别的业务部门的系统运行，云管中心是要担责的。

这真的是十分滑稽了，微服务，容器化原本是为了享受其动态的优势，系统上云后，企业在IT系统的容量与资源管理模式上依然延续原有模式，就让云平台的优势荡然无存了。不过云管中心的人也很无奈，他们的IT预算是固定的，目前云平台的扩容资本金与当年没上云时候相比是持平的，不过因为小型机不采购了，因此购买到的算力其实是比以前要多很多的，因此他们也无法向企业申请更多的资金用于云平台的扩容。不过因为系统建设速度太快，他们的云平台资源目前也十分紧张，因此他们虽然可以满足某个系统的扩容需求，但是必须满足一些系统资源使用率的阈值才行，否则大家都来申请资源，他们就抓瞎了。

关于上云后是否省钱的事情是另外一笔糊涂账，用这种碎片化的管理模式去管理动态的云，资源使用能变得更有效，这只能是一句空话了。如果系统的动态伸缩无法实现时，那么新IT架构就只剩下复杂性了。

这种复杂性让系统变得愈发脆弱，拆得十分零碎的微服务不仅不能有效的使用云平台的融合资源，反而出现了无数的弊端。原本一个复杂的业务流程是在一个WEBLOGIC实例中完成的，模块之间的调用成本极低，效率极高。目前拆分成数十个微服务后，完成同样的模块就需要调用数十个接口。前阵子我看过一个系统的优化报告，其中一个模块每次执行需要好几秒钟，原本以为只要问题在SQL上，后来从ARMS中发现SQL响应并不慢，只有100毫秒左右，每个调用在几十毫秒到几百毫秒之间，算一下总时间，也差不多几秒钟了。想要把这个模块优化到非功能性需求要求的2秒钟之内，还是有一定挑战性的。

用适当的架构做适当的系统，选择最简单的架构来做系统，让研发专注于业务逻辑。这是IOE时代的主要架构思路，也是IOE成为IOE的关键。随着IT技术的发展，软件定义概念的流行，目前留下的技术层出不穷。很多企业还没掌握好一种新技术，更好的，更新的技术就出现了。于是企业IT就从以业务需求出发变成了跟着创新走了，这导致了一种新的不和谐，那就是业务跟着架构走而不是为业务选择合适的架构了。在这种情况下，一旦系统的复杂度超出了研发与运维人员的能力范围，那么系统出问题就是早晚的事情了。

企业应用系统架构的优化演进，必然伴随着企业在IT管理方面制度的变革，以及企业在IT成本投入策略的变化，这样才能让系统架构演进获得有效的保障。实际上大型互联网企业在这方面做得不错，而到了传统企业，一切都变味了。学习互联网企业先进的技术架构这一点也没问题，因为这两年互联网企业也在大力输出。但是互联网企业在管理方面的先进经验，大家都没有学到，一方面企业觉得管理是自己的事情，不能照搬，另外一方面是互联网企业在这方面也没有什么油水可捞，因此也教得也不尽心。因此往往我们只获得了新技术的复杂性，并没有获得让新技术与自己业务更好融合的内功心诀。这样的学习借鉴，是很难成功的。