偶尔翻翻朋友圈，会发现之前在 IBM、Dell、Intel 的联系人，纷纷加入了阿里云、腾讯云等国内企业。能直观的感受到，国内企业在业务扩张、技术人才吸引上力度更大，重金投入。另一方面，也体现出技术人对个人职业发展的重新思考和突破。

刘冠军 2020 年年底加入腾讯，目前就职于腾讯云产品部微服务中心架构师组。工作重点是关注云技术的最新动向、挖掘客户需求，丰富和完善腾讯云的 PaaS 产品，为客户提供腾讯云 PaaS 产品方案，帮助客户实现数字化转型和业务快速迭代的需求。

在此之前，刘冠军任职于 IBM 中国实验室 12 年，在事务处理、网关及监控、分析平台相关技术和银行核心交易系统架构方面有着丰富的经验。

之前十多年 ToB 产品研发的经验，了解 ToB 业务发展的过程，了解企业级客户的痛点和他们的一般商业模式，所以刘冠军在 ToB 产品的研发流程、产品规划的方法论等方面积累的经验，以及原有的客户圈资源，都是可以借鉴并运用到腾讯云业务上的。我想这也是腾讯云吸纳人才过程中最为看重的能力。

正视 Gap，避免速朽

也许有人会认为传统企业和互联网企业之间存在巨大的技术 Gap，身处这两个圈子里的人之间也存在 Gap，实际上这种现象和业务量大小或者宣传力度强弱有着紧密的关系。

刘冠军说这里有个误区，传统企业像 IBM 仍然在最新的云和 AI 等技术上有巨大的投资，传统企业和互联网企业之间并不存在巨大的技术 Gap，都在大家看好的赛道上持续竞争，只是身位的变化问题。当然，对于刘冠军个人来说，是存在这样的 Gap 的，因为之前主要是在传统的集中式技术领域，而且是相对封闭的大型机领域。所以加入腾讯是他个人的一次转型之旅，是接受新挑战和新机会的一个过程，“很忐忑地享受这个过程，也期望能在新的领域里再次做出一些成绩。”

关于个人技术上的 Gap，刘冠军对待这个问题也很坦然，首先，要承认这个 Gap，正视差距才能驱动自己努力学习和追赶。其次，进入具体的执行层面，要看到新技术也不是凭空产生的，新旧技术是有通用性、相似性和传承性的，面临的客户问题其实也是相似的。

比如，从系统总体架构来说，不管是集中式还是分布式，都要追求高性能、高可用、高伸缩、高扩展和高安全。

比如，高可用，都要通过资源的冗余设计来实现故障的自动转移，只是传统集中式系统里硬件的冗余设计占比很高，而反过来，分布式正是因为默认硬件的非可靠性而从软件架构方面蓬勃发展出了各种云原生技术。举事务方面的一个例子来说，刘冠军过去的经验主要集中在集中式系统上实现两阶段提交协议的事务中间件，如何保证高并发的事务处理。进入互联网分布式领域，面临的客户问题是相同的，也发现很多流行的分布式事务框架都跟两阶段协议有千丝万缕的联系，比如 TCC，也是分成两阶段，第一阶段大家各自预留资源，向协调器反馈结果。第二阶段根据反馈结果执行确认或者回滚。再比如 Saga，进一步把预留资源和确认操作两步合一步，变成了直接执行，失败了再重试或者回滚作为补偿。这其实是一种两阶段协议更进一步的乐观主义的实现。

所以总结来说，这两种技术之间的平衡不光是技术上的学习与补齐，更多的是新旧东家，前后职位的差别在个人心态上的平衡。正如《傅雷家书》中说到：人一辈子都在高潮和低潮中浮沉，惟有庸碌的人生活才如死水一般，或者要有极高的修养，才能廓然无果，真正的解脱。只要高潮不过分使你紧张，低潮不过分使你颓废，就好了。

是什么在推动传统客户做架构转型

刘冠军之前所接触的客户主要是国内外传统大银行。从他的视角来看，面对今天互联网企业的跨界竞争，传统银行在业务竞争和人才竞争上的压力都非常大。不运用新的技术，业务发展就很缓慢，逐渐会被市场边缘化。没有新技术的氛围，人才也得不到培养与发展，就会面临不断流失的风险。基于这样的大背景，传统银行在架构转型上主要考虑了“稳、敏”两种形态的兼顾与平衡。

稳态，指的是很多涉及账务的系统必须得到确保，不能出现问题，因为一旦出现问题，牵连的范围会很广，责任重大。另一方面又要加强敏态，要求业务要适应市场的激烈竞争，像互联网企业一样快速迭代，推陈出新以抢占先机。这就需要分布式技术特别是最新的云原生技术的有力支撑。在稳、敏两种形态的要求下，很多传统银行出现了混合云的发展布局。稳态要求下的数据和交易核心系统会部署在自建机房中，逐步有序地推进分布式技术改造到私有云平台部署，以稳和安全优先。敏态要求下的系统则可以在符合监管约束下选择部署在公有云、行业云等多种形态下，以节约成本和快速迭代为主要目标。

所以刘冠军总结说，传统架构的转型是企业内因外因加上时代方方面面共同作用下的必然结果。

架构转型的痛点

传统企业架构转型，势必会涉及到上云，应用云原生技术，其中存在很多痛点问题，这一点，刘冠军很清楚。

根据康威定律，首先面临的就是一个组织结构的问题，什么样的组织结构决定了什么样的系统架构。

在刘冠军看来，很多传统企业转型过程中第一个痛点就是组织结构的调整，比如云原生倡导的 DevOps，就要求开发、测试、运维一体化，但是很多传统企业还是维持着过去开发和运维各自独立的组织结果。两个组织间就会存在开发要求快速出版本，而运维希望慢一点维持稳定的 KPI。这只是一个小小的缩影来说明康威定律反映出来的问题。

或许有人会问，那为什么传统企业不能大刀阔斧地改变组织结构适应今天云原生技术的要求呢?这是因为很多传统企业历史遗留系统的问题。

在中国，各大银行上世纪 90 年代开始做数据大集中，21 世纪的第一个十年完成了这一目标，距今天也就十到二十年的历史。这期间已经遗留了很多 IBM、Oralce、EMC、HP 等传统 IT 厂商的系统，这些系统虽然因为价格和封闭颇受诟病，但质量上稳定可靠，依然在各个传统企业里发挥着重要作用。这是我们 20 年内的积累，再放眼看看国外的情况，由于他们 IT 起步远远早于我们，所以遗留系统更为复杂。在欧洲、北美甚至是日本都有核心系统使用了多代 IBM 交易中间件的情况，这些系统也是每个时代最领先的技术结晶。

所以，过于沉重的历史遗留系统使得组织结构的变化并非轻而易举。但也存在可能性，很多企业也在尝试着分拆传统部门，留下少部分人员运转遗留系统，更多的人手转入新的部门采用新的技术栈。

接下来面对的就是人才技术转型问题，和新旧系统的协作问题。拿新旧系统协作问题来说，很多传统大银行采用了瘦核心大中台的方式来改造遗留系统。简答来说，就是把之前的核心系统拆分开来，把非核心交易部分通过剥离、分解、服务化迁移到云平台实现云原生改造，再通过 RPC 或者 HTTP 等协议替换之前的共享内存模式或者专有协议，让它们和核心交易系统联通起来。这类改造从系统层面来说一般会带来响应时间的增加，但是会极大提升系统和业务的灵活性，所以如何掌控和平衡这两者的关系，也是传统企业上云过程中始终要把握的核心问题之一。

另一个方面，业务和系统从传统的单体应用剥离过程中，需要方法论来指导，这就是领域驱动设计(DDD)为什么会如此流行的原因。但是这套方法论并不像云原生技术那样容易上手，它更多是一个咨询服务和项目经验的积累过程。

云原生不是银弹

虽然现在云原生、云计算等技术很成熟，但是传统企业还是会继续使用大型机吧?您觉得在什么时候，或者什么契机下，传统的企业会大面积，或彻底的上云，采纳云原生技术?

刘冠军说，这是一个很有趣的问题。记得几年前他去英国实验室，和不同年龄段的同事讨论了中国客户大型机下移的战略趋势，他们当中一位工龄甚至超过了刘冠军年龄的人说：自我们加入公司以来就在跟客户讨论大型机下移的问题。那一刻刘冠军才意识到，这其实是一个持续了 30 年的话题。

其实仔细想想，正如《人月神话》里提到的：No silver bullet(这世界没有银弹)一样，没有一个标准答案能解决这个问题。

20 世纪 60、70 年代是大型机统治时代，但随着技术的发展，很多细分领域的业务会孕育出更加合适的技术来承托，所以就会有各种新技术来分享大型机的市场份额。直到今天，事情的本质并没有发生变化。

认清这个本质，那回答传统企业是否会大面积或者彻底上云，甚至采纳云原生技术这个问题就显得比较容易了。刘冠军从三个方面来分析传统企业的某些业务是否需要采纳云原生技术：

第一从需求方面，这个业务是否需要经常迭代和变化?比如某些交易业务、ERP 业务，本身很少改变，它们采用云原生加强业务迭代的动力不足;

第二从性能方面，某些交易业务如证券交易 0.1ms 的延迟可能引起的都是具体的收益和损失差别，而微服务化、容器化都很有可能影响原有单体的性能;

第三个则是从数据一致性层面考虑，如果某些系统对数据强一致有硬性要求，采纳云原生技术似乎也不是非常明智。

因此，根据刘冠军的个人判断来说，当今 IT 世界大面积上云是不可阻挡的历史潮流，彻底上云或者云原生则不一定，因为云也成不了那个银弹，何况技术本身也是一个不断发展的过程。

云原生趋势下架构设计如何演进

刘冠军说，他所理解的云原生技术主要包括微服务、DevOps、CI/CD 和容器化与 Kubernetes 容器编排等一系列技术。这些技术本质上是想提供敏捷化的开发能力，标准化的部署与运维能力，使各种使用者(业务、开发与运维)面向云的环境得以从容漫步。公共服务或者共性的非业务特性的东西会进一步抽象下沉到基础设施之中，以标准化为目的的容器和 Kubernetes 似乎已成了云原生体系下的“操作系统”，以及 Service Mesh 都是这一趋势的很好表现。