搞金融专有云计算一年余的感想
2023-08-11, 杭州
作为金融科技行业甲方，搞了下云，技术方面有些憋了很久的话，感觉想要说出口，和大家一起探讨。
合理的云计算改革方向是自顶向下的。是业务应用先演变云化，然后基础设施去适应业务需要，而不是为了上云而上云
直接讨论一个平常的情况，你把传统形态风味厚重的ERP、CRM应用挪到云上，不难发现，挪和不挪区别不大。资源文件堆到OSS和堆到静态文件目录下有什么区别呢？连上云原生数据库，分库分表等高级特性有用吗？还不如有点意识，搁云上是开启防勒索，搁云下每天半夜把库滚一份到远程服务器上冷备，不也是防勒索。
对于非云原生的应用（个人感觉国内集成商说的云原生比起榨干Cloudflare免费额度的小函数来说甚至算不上上云）来说，应用本身先发展，然后我们再需要各种云计算概念去支撑。以一个商户面客应用发展推演整个演化流程。
-
现阶段。整个应用就是小作坊搓出来，传统的servlet上面糊点Spring，然后硬生生加层扔进docker里，扔进云上，实际上也没有用到容器的部署、漂移、恢复能力，每次上线还是手动启停容器一个小时，手动改云上软LB的配置去摘流，痛苦面具。但说它有云的潜力也对，商户店面分租，多少也算SaaS，很有横向扩展的需求潜力。
-
演化到讲究PaaS的阶段。伴随业务发展，需要支撑万级并发，架构怎么做？稍微现代的方式，搞经典Java分布式，依赖几个虚拟机做高可用分布式的集群注册中心，可以用命名空间划分下不同的模块，然后DevOps推上去跑脚本，借注册中心和微服务协议自己的恢复能力，灰度摘流更新接流就好了。
-
真正讲究IaaS的阶段。业务持续发展，大江南北的人都要走你的系统下单，你光是收单，单点或双活的注册中心都要撑爆了。这个时候，祖国南北都堆可用区让人快速就近访问服务器；GTM做全局流量优化；静态资源前移到CDN加快分发；高性能API网关甚至服务网格分流查询浏览和秒杀交易，统管接口鉴权避免被人一秒脱裤；加点分析型数据库跑埋点跑客群模型跑风控；服务器达到了万台十万台级别，局部资源使用率升起来就要提前关注告警。
您看，这么多需求产品叠起来，再加上统管需求，才构成了我们现今超大超重的IaaS。
而另一些情况下，业务演变期间因为某些方面的侧重，会部署一些垂直领域的极端解决方案，比如数据备份有高要求所以堆了NBU，入侵防护有高要求所以堆了APT全流量，局部地方数据交换很猛烈所以搞了集中式存储乃至InfiniBand……上云之后这些问题反而不好解决了，多出来的部分我也用不着。那么，上云干嘛？
所以监管部门陆陆续续出指标让大家上云，也不能简单从淘汰IOE、基础设施技术栈换一套去理解。 不是意味着用最新潮的云技术组件就叫上云，而是成熟的云体系中各类产品能容纳各种体量的应用，云上应用系统充分利用云基础设施提供的可观测、可复制、可迁移、轻量化的优势。 系统集成商也应该充分意识到这一点。
业务连续性第一，可观测性第二，可维护性第三，性能第四，“云功能”反而不重要
业务连续性第一毋庸置疑，不追求业务连续性的场合爱用什么技术栈都可以，不作讨论。接下来，为什么把可观测性放在可维护性之前，因为追求业务连续性时，观测比维护更重要。
可用性观测方面，云平台提供的可用性观测和告警能力真的能紧贴业务应用吗？如果业务应用设计上通用点，不贴着这个云平台的专门feature来设计（尤其在有的云平台技术选型很诡异，网络射来射去，underlay入侵乃至卡了overlay设计一道的情况），链路追踪和告警体系是不是就荒废、失灵了？
交易可观测方面，举个极端的例子，大规模机器挂了或者网络断了，假设有一些不平账的交易数据。重新对账对平的必要前提是把云上机器开起来吗？当然不是，是你能看得到拿得到追查得到这些交易数据。真正紧急的时刻，搬几台物理机过来直接并网，或者启用尘封的VM区，应用跑起来，上下游地址改改接过去，把丢失的交易拉去对账。这个时候要你云的可维护性有什么用？如果云上出事了第一时间看不到，出事后事故现场数据拿不到抢救不出来，那就真完蛋了。云相比较传统架构，带来的可维护性是甜点（甚至有时会开倒车），不是必要增益。但是现在市面上好些私有云平台，主打的是“产品化”，做个KVM高级套皮，结果镜像不方便旁挂，虚拟磁盘不方便第一时间取出来，反而为了产品和封装包了好多道意义不明的抽象，没有必要。
更有甚者，为了一次打包卖整个平台和后面的人工服务，整个云做得很封闭，传统VM架构本来能轻松（在硬件旁拉条线出到特定设备就可以）做到的流量可观测、物理机可观测，到云反而没有这样的能力了，设备旁挂会影响云的稳定性，组件取代会影响云的稳定性，你必须用云提供的一个粗糙封闭的云监控组件、日志组件做个大概的观测行为。这就好比你在路边摊吃桂林米粉，虽然不太正式，但什么料都可以自己加，吃得挺开心的，突然被人手脚绑起来，眼睛一蒙，你只听见饺子被呼啦倒在桌上的声音，然后被人按头吃桌饺。
又一个灵魂拷问，云的可维护性真的比传统VM方案要好么？回顾一下运维流程，不外乎是：人，界面，接口，平台本身。新鲜的WebUI是界面，古朴一点的WebUI也是界面，virsh也是界面，x11/wayland也是界面，在对界面进行比较时，技术是次要的，从交互设计角度来看，易于操作、易于理解、防呆、操作效率等方面才是打造界面最该关注的事情。
然而许多云厂商的界面似乎并没有经过UX团队的设计，抛出来的错误也不明就里，该做的前端数据校验卡口没做好，本来命令行能脚本批量的操作到GUI上反倒只能挨个点，面对大量数据加载时前端性能优化极差，访问控制模型做得比直接看/etc还杂乱……我列举的这些都还只是比较浅表的问题，但似乎好些云厂商在界面上，重复踩这些人类软件设计和交互设计已经踩了几十年的坑。
接口亦如是。国内一些平台的云管接口的风格让人感觉是做业务转过来似的，旧版本新版本接口层层叠加，参数传多传少不在乎，跑起来就是了；还有些很关键的接口，抱歉没做好不开放。最后反而导致，按传统VM架构百来台物理机cockpit或者ansible playbook糊一下，都比在已暴露的接口上做二开方便。
看当今云交付的时候往往喜欢打包一些先进的“云组件”“云特有功能”来卖。这些功能真的重要吗？云上面能一键拉镜像创建主备从高可用数据库，云下不也能拿脚本和预制镜像一次跑出来么？横向对比垂直领域厂商的方案，价格、性能、可用性和关键特性，云组件真的存在足够好的优势吗？弹性伸缩、节约资源，在专有云存在吗？从我摸过的好几家专有云厂商，对标垂直领域的网络、安全、存储（甚至有的厂商就是组件的提供商，不知道为什么上了云阉割成这样糟糕）等方案来看，并没有很显著的体现。
可以展望的云计算基础设施方向
这一部分写着心情比较复杂，也掺杂了大量的个人感受。一方面我们有稳健的国外老牌大厂的传统架构（主机、小型机、集中式存储等），另一方面我们有国产化指标，再一方面国外的云原生架构又演化出了很多更新潮的形态（Serverless、行数据库、向量数据库、云日志服务等）。所以这里的展望，还是从国内政企的专有云计算怎么走去思考。
扣回到2当中提的几个点。
业务连续性方面，计算和网络高可用，传统的vSphere vSAN集群和VEEAM等完备的VM服务能够做到物理机故障时热转移，对计算实例毫无干扰，而国内许多基于KVM & OpenStack的方案似乎仍有欠缺。但这几年，国内容器发展还是比较蓬勃，通过更智能的反亲和性部署，更迅速的容器网络流量调整，在不需要变动硬件虚拟化引擎和操作系统内核的前提下，从应用层面保障业务连续性是完全可行的。会是类似Linkerd2的透明服务网格+强调智能又高度灵活的拨流的模式吗？我感觉那样技术是先进的，但未必会符合国内开发的口味。
保守点想用虚拟机实例做高可用怎么办呢？寄希望于LVS或者内部用容器打散好的负载均衡，寄希望于平台本身在物理机上能把集群VM打散，通过探活和切端口，过上一种传统的高可用生活。存储高可用，这个感觉国产数据库普遍做得比较成熟了，然而跨地域调度同步的对象存储块存储等，似乎还在期望更好更快更稳的协议。
可观测性方面，直言不讳，现在的专有云平台产品就是干不过每个垂直深入的可观测性领域（网络、主机、应用、安全）的公司。然而目前云厂商的专有云团队拥抱可观测性似乎并不积极。上文说的容器可以以抽象带来的性能损耗为代价解决很多应用级观测性问题，计算上，花样玩耍控制面，对每个node每个pod都看得死死的；网络上，花样制造各种overlay网络，然后对里边流着的东西拆包、导出、统计，什么都有了；但抽象以下的部分依然需要保证，那还是需要看云厂商自身产品的造化了。数据库的可观测性，国内倒也有不少厂商深耕得不错，SQL级的性能审计已经有相对成熟的商业方案，我甚至觉得过几年会卷出语法树级的（逃）。
可维护性方面，讲究一个兼顾深度自动化和简单随手开；IaC吹了好久了，然而国内还没见几个厂商尝试深度耕耘推广，大抵确实极端了些；从老运维视角，简单点的操作界面上点点，复杂的操作写好脚本批量跑，恰好合适，然而现在诸多专有云平台，CLI工具都坑坑洼洼，让人很难有这种按类适应的环境。怕是要等到哪家厂商CLI+API都打磨好，才好为广泛的二开铺平道路。当然，也已经有厂商试图把API聚合起来去搓一些统一的云管平台，但正如传统开发笑话描述的一样，前十三个标准看着都不满意，打算做个统一标准——然后现在世界上有第十四个标准了。还是要相信老运维之力，CLI能抹平云管和传统运维脚本开发的沟壑，API能抹平云管和复杂运维工具二开的沟壑，从而适应各种从纯手动到纯自动的场景。我们老嗨客脚本小子甚至都不管你什么平台，蚁剑冰蝎CF哥斯拉，一键托管。
剩下的部分，写到这里已经困了，还有一些美好的愿景暂时难以比较完善地描述。还是睡吧，梦里什么都有，万一哪天拿个树莓派把网线怼上去就能一键托管进aarch64计算资源池呢。