甜橙金融（天翼电子商务有限公司）成立于2011年3月，是中国电信股份有限公司全资子公司天翼电子商务有限公司的核心品牌，是中国电信布局互联网金融的重要板块，是互联网金融行业领先的创新企业，是中国人民银行核准的第三方支付机构，中国证监会核准的基金支付结算机构。甜橙金融在2016年便完成了上云操作，截止到2018年7月底，甜橙金融整体交易金额超过8000亿，日交易笔数8000万，并发支付处理能力达到每秒1万笔，累计用户数5亿，月活用户4000万。

翼支付公司总监，现任运维中心负责人。2011年加入甜橙金融，专注于基础设施运维，推动了传统运维转型自动化运维，基础设施整体上云，经历企业从传统运维转型自动化运维全过程。

银监会“十三五”规划的发布加快了金融业上云的步伐，但业界并无上云的先例，整个过程就像摸着石头过河，各家的经历不尽相同。甜橙金融在上云过程中颇多可圈可点的领先实践，笔者近日专访了甜橙金融信息技术部总监陈裕颋，听他讲述上云过程中的体会心得。

怎样定义和监控一个业务网络？

陈裕颋表示，监控分两个层面，一个是大家常说的业务监控，更多地关注交易笔数、交易成功率等偏向业务的数据。另一个层面是从基础设施的角度保障业务的稳定性，主要包括链路是否发生抖动、每一个服务之间的交换传输是否成功送达以及出口链路的整体情况。因此，通过基础设施监控叠加业务监控，运维团队能更好地确保业务的服务质量。

APM和NPM这两类产品甜橙都在使用，相对来说甜橙金融目前最关注的是适合业务使用场景的产品。通常情况下，APM和NPM能形成一个互补的监控网络，例如用户想抓到一些慢SQL的交互过程时，APM产品具有先天的优势；NPM的优势在于其侵入性较小，能够快速和轻量部署，在主链路调优场景（发现瓶颈点）中的使用较多。陈裕颋认为，NPM在保障底层网络的监控、信息的传达、异常问题的复现和回溯是非常有价值的。一个典型的场景是，当用户报障了平台方才能发现问题，然后通过监控和抓包等待问题再次发生时才能定位故障点。部署了NPM产品之后，当用户再报障时，平台方就能立即检索当时的网络状况，进而对问题进行初步的定位和定性。

当用户报障之后，平台方通常会采取一系列手段来解决出现的问题，往往会先排查基础设施平台信息，确认底层链路和TCP建联的握手情况是否正常。然后借助APM把链路瓶颈点从一个黑盒子变成灰盒子甚至白盒子。当然，APM的实施成本和价格还是比较高的，陈裕颋表示。

如何进行统一策略管理？

甜橙金融的上云的过程等于一次重生，陈裕颋如是说。甜橙金融上了SDN之后，对研发和业务来说是利好，但对运维来说，策略的有效性依然缺乏监控，东西向流量的监控和排障手段亦有限。在上云过程中，所有的部门把全部的业务都梳理了一遍，团队一共做了两个维度的工作。

第一个维度是简化和规范。最初业务的端口开的五花八门（有80、8080、8030、同样一个Web Server的端口大家用的都不一样），甜橙金融对相同业务的端口做了统一分配，继而像做信道划分那样对不同的中间件预留了不同的端口号，这为后续的规划和排障都带来了便利。第二个维度是策略验证。通常情况下运维部门难以判断策略的使用率，产生这种情况的原因较为复杂，可能是历史遗留问题，也可能是业务下线后的残留配置。借助NPM工具，运维团队可以将数据流和网络策略进行比对验证。对于策略的删除，一般需要业务方发起（像走OA流程一样）最终由运维平台进行删除操作。在策略验证过程中，运维团队通常能发现热点流量，这对扩容、排障均有指导意义。

甜橙金融对开源、自研和商用的采纳标准

甜橙金融坚持以自研为主，在上云初期由于团队的技术还在积累阶段，甜橙金融采用商用产品的比例较高，随着上云之后团队技术实力的不断增强，采用开源加自研组件的比例逐渐上升。目前绝大多数（约70~80%）的组件都是开源加自研实现的；有一些是合作伙伴定制开发，并最终掌握知识产权和源代码的组件；目前甜橙金融仍有部分组件采用商用产品。

甜橙金融通常会根据自身的技术储备和业务的实际需求来决定是否采用商用产品。简而言之，对于距离甜橙金融技术栈比较远、需要投入大量人力物力但产生的影响比较少的底层技术会选择商用产品。使用开源组件的经济效益在业务达到一定规模之后才会显现出来，这其中有一个平衡点。陈裕颋表示，最终甜橙金融会进入一个开源加自研为主、少量商用产品为辅的稳定状态。

对于商用产品，陈裕颋表示各家厂商都有自己的特点，有的处理8583报文较专业，有的对互联网流量的拆解更细致，还有的厂商特别擅长内网东西向流量的采集和虚拟化网络流量的采集。当被问及采用云杉网络DeepFlow®的原因时，陈裕颋表示，甜橙金融目前的需求更偏向互联网化以及内网的东西向流量采集；DeepFlow®在实际实施时的部署成本可接受、对系统的侵入性较小、与甜橙金融业务的契合度较高；另一方面是云杉的团队比较专业和踏实，在了解到甜橙金融的业务现状后能比较快速地呈现出了平台方希望看到的网络流量和网络映射的情况，这对保障甜橙金融底层平台的稳定性有很大的帮助，为甜橙金融后续的基础设施扩容和优化提供了依据。

消除业务发展的瓶颈以及网络角色的变迁

甜橙金融上云之前的瓶颈点在于，研发和运维两个团队存在沟通语言上的GAP，研发关注的永远是业务模块，运维关注的永远是IP地址、网段、端口号等等，二者之间缺少一个翻译的机制，每次的扩容都会花大量的人力、精力和时间去讨论和准备方案。甜橙金融上云过程中，采用了数据中心主流的二层网络方案，基础设施改造的主要表现为万兆网络的接入和实现了低延时转发。这带来的直观感受是，网络的转发和处理性能更快了，同时平台的承载能力更强了。

上云之前的并发处理在极端场景下尚不理想，原来烟囱式的架构是一个因素，传统网络架构的确比Leaf-Spine架构的网络转发的延迟要大。通过上云的虚拟化和自动化技术，甜橙金融实现了资源的弹性伸缩。经过近几年“5•25活动”的历练，在这种千万级用户的秒杀实战中，甜橙金融逐渐能应对这种高并发流量的冲击，从而保障了业务的稳定和持续发展。

在企业中，网络更多地承担着基础服务的角色，主要负责把网络流量引进来交给后端的服务器去计算。随着分布式云计算架构的引入，一次交易业务的完成由原来的3~5次交互变成了30~50次，将来的交互甚至会更多。这时网络中任何一个波动都会对这笔交易的成功造成影响。随着分布式的引入，原来的网络瓶颈可能在南北向出口，现在的瓶颈可能出现在了内网东西向流量。目前的万兆低延迟网络在未来2~3年内能满足甜橙金融整体业务的发展，目前业务的诉求点在于低延迟而非带宽，万兆网络是一个性价比非常高的方案，陈裕颋表示，相对而言带宽的储备和扩容都比较容易。

关于新技术的采用及创新

甜橙金融的SDN采用了ACI方案、主机虚拟化采用的是定制化Docker结合适量VM的混合部署方案。据笔者了解，采用容器上生产的企业并不是很多，并且以互联网公司为主。面对我的疑问，陈裕颋哈哈大笑，他表示甜橙金融关于容器的选型和技术储备已经做了很长时间；当时技术团队评估的结论是，对于甜橙的业务来说Docker与甜橙金融整体技术栈的匹配度相对更高，但是需要较长时间的技术积累和储备。

对于Docker自身的网络问题，SDN技术的引入恰好覆盖了Docker网络调度能力的不足，由于团队早期的技术积累、加上合作伙伴的一起改造，甜橙金融在使用Docker上并没有遇到太多网络问题。甜橙金融对Docker的使用也进行了定制化，更侧重于考虑支付行业业务对于资源隔离的诉求；再加上Docker相对VM更轻量、其模板定制更灵活，使得甜橙金融能够把低负载的业务更密集地汇聚在一起，因而显著提高平台的资源利用率。

由于涉及到部门权责和利益的原因，很多企业的改革存在内部阻力。但甜橙金融似乎没有这个困扰。陈裕颋认为，各个企业的技术背景和文化氛围不尽相同，甜橙金融上云得到了整个公司管理层到技术团队管理层的大力支持，在推动上云的时候内部阻力比较小。另外，技术部门的领导十分注重创造一个使用新技术的氛围，这也是很重要的一个因素。甜橙金融的技术氛围比较好，团队更愿意去尝试和接触新技术，这些新技术的确又能给业务部门带来较好的服务和使用体验，业务部门的接受度因此更高，这种相辅相成的局面更促进了上云的推进。

在甜橙金融内部，运维团队会将很多权限下发到了业务方手里，随着业务部门在实际操作过程中的切身体会和感知，他们逐渐认识到，配合平台去做一些标准化改造和流程规范的梳理，最终受益的是所有的业务方和整个公司的平台。目前，甜橙金融运维团队遇到的主要问题是引入新技术带来的学习成本以及外部因素导致的故障。为此，集团内部也在不断举行以内部业务创新、对外技术交流互动为主题的活动。