自如在云原生路上的摸索和尝试，聊聊那些折腾过的坑和经验

（来源：知乎专栏“技术团队的自如云原生实践”）

一开始我们觉得云原生就是个好东西,容器化、微服务、动态管理，听着就高级，感觉上了云原生这趟车，以后扩容、部署、故障处理就都能自动化了，运维能省老大劲了，所以当时团队热情特别高，决定全面转向云原生架构。

（来源：团队内部技术复盘会议记录）

但真干起来才发现,第一个大坑就是微服务拆分，原来我们是一个挺大的单体应用，虽然部署起来笨重点，但起码功能都在一块，出了问题也好查，一拆微服务，问题就来了，拆多细才算合适？一开始我们有点理想化，觉得越细越好，每个小功能都搞成一个服务，结果呢，服务数量爆炸式增长，光是服务之间的网络调用就复杂得让人头疼，最要命的是，原来在单体应用里一个本地事务就能搞定的事，现在得搞分布式事务，这东西太复杂了，我们折腾了好久，中间还因为数据不一致出过线上问题，后来我们学乖了，不能为了拆而拆，得根据业务边界和团队结构来，先粗后细，慢慢来，这是个深刻的教训，微服务不是银弹，拆不好反而会增加巨大的复杂度。

（来源：工程师A的个人技术博客“我们的K8s踩坑记”）

第二个折腾得够呛的是容器编排,我们选的是Kubernetes，学习成本真的高，那些概念什么Pod、Service、Deployment、StatefulSet，一开始真是云里雾里，部署环境也挺麻烦，本地开发环境、测试环境、生产环境，怎么保持一致？我们一开始用本地Docker Compose，但和K8s集群的行为差别很大，经常是本地跑得好好的，一上测试环境就挂，还有配置管理，把配置硬编码在镜像里肯定不行，用ConfigMap和Secret吧，更新了配置应用还得重启才能生效，不够灵活，后来我们引入了Helm来做应用打包部署，算是规范了一点，但Helm模板的复杂度也不低，日志收集也是个大问题，原来虚拟机时代登录上去看日志文件就行，现在容器漂来漂去，日志散落在各个地方，我们不得不引入了一整套EFK（Elasticsearch, Fluentd, Kibana）栈，又是额外的维护负担。

（来源：团队分享PPT“稳定性保障之路”）

第三点,也是让我们最紧张的一点，就是监控和稳定性，系统变复杂了，故障点呈指数级增长，一个服务慢了，可能引起连锁反应，导致整个系统雪崩，我们一开始的监控只盯着CPU、内存这些基础指标，根本不够用，等服务真出问题了，才发现是某个依赖的第三方API响应慢，或者数据库连接池满了，我们花了大量时间搭建和调优Prometheus和Grafana，定义各种业务指标和告警规则，光有监控还不行，还得有韧性，我们尝试着用Hystrix做熔断，但集成起来也挺费劲，后来我们实践了混沌工程，就是主动在测试环境模拟故障，比如随机杀掉个Pod，或者模拟网络延迟，看看系统会不会瘫掉，这个过程很痛苦，经常把自己搞出故障，但确实逼着我们提升了系统的容错能力。

（来源：技术Leader在行业沙龙上的分享）

成本控制也是个意想不到的坑,本以为用容器按需分配资源能省钱，但K8s集群本身的管理节点就要钱，那些云上的负载均衡器、块存储、流量费用，七七八八加起来，一开始几个月账单出来吓一跳，比原来用虚拟机的时候还高，我们才开始重视资源配额和限制（Resource Quotas和Limits），给每个命名空间、每个服务都设定合理的资源上限，避免某个服务失控把整个集群拖垮，同时也要定期清理没人用的镜像、无用的存储卷，这些细节不注意，钱就悄悄流走了。

（来源：团队Wiki“文化转型心得”）

我觉得比技术更难的是人和流程的转变,开发人员不能再只关心自己的代码了，还得懂容器镜像构建、懂K8s的YAML配置、懂监控告警，运维人员的角色也变了，从传统的机器维护变成了平台和工具的维护者，这就需要大量的培训和文化建设，我们推行了DevOps，强调责任共担，但改变大家的习惯不是一朝一夕的事，CI/CD流水线的建设也磕磕绊绊，自动化测试覆盖率不够，不敢完全自动部署到生产环境。

云原生这条路绝对不是一帆风顺的,它是一套全新的理念和技术体系，需要技术在实践中的不断打磨，更需要团队意识和流程的配套升级，我们的经验就是，别想着一口吃成胖子，从小处着手，从一个应用开始试点，遇到问题解决问题，慢慢积累经验和工具链，逐步推广，那些坑现在看来都是宝贵的财富，逼着我们变得更专业、更严谨。