数千台服务器，千万用户量：居然之家两年云原生改造历程

2009 年，居然设计家(Homestyler)研发团队正式成立，开始进行第一个版本的探索；如今，十年已过，居然设计家正式更名为躺平设计家，用户量近千万。在两年多的云原生实践改造过程中，整个团队经历了从运维数千台服务器再到全部交付给云，从探索上云到利用 Serverless 和 Service Mesh 完成云原生改造，最终整体可用性达到三个 9 以上，同时 IT 费用削减了近一半，本文分享了躺平设计家的云原生实践历程。

自 2013 年由 Pivotal 的 MattStine 首次提出至今，云原生（Cloud Native）这一概念正在逐渐重塑整个软件生命周期。架构良好的云原生系统在很大程度上是自修复、经济高效的，并且可以通过 CI/CD（持续集成/持续交付）轻松更新和维护。好在构成云的服务器、磁盘和网络与传统基础设施相同，这意味着几乎所有优秀的架构设计原则仍然适用于云原生架构。但是在云中，关于这种结构如何执行的一些基本假设会发生变化。例如，在传统环境中配置替换服务器可能需要数周时间，而在云环境中仅需要几秒钟，这些都是应用程序架构需要考虑的内容。

在云原生实践的系列采访中，InfoQ 先后采访了阿里巴巴、腾讯、京东、青云等众多厂商，对值得关注的开源技术及相关落地实践进行了初步探索。本文，InfoQ 对居然之家的躺平设计家研发总监谢康进行了独家专访，了解这家企业从传统单体架构向云原生演变的实践路径。

实践背景

躺平设计家原名居然设计家（Homestyler），是居然之家旗下专为家装设计打造的一站式服务品牌，包括相关工具和社区，主要服务于家装设计师，目前国内有超过四十万的设计师活跃在该平台之上，国际设计师则已经超过九百万。

在进行云原生改造之前，居然之家的技术栈相对传统，早期的核心算法和系统都是基于 Scala 和 C++语言搭建，而如今已经很难招聘到经验丰富的 Scala 工程师，短期内用 Java 重构整个平台代价又显得过于高昂。与此同时，整体迭代速度非常慢，对需求的响应周期较长，创新能力也出现明显不足，服务器运维、网络等成本开支逐渐难以承受。

成立早期，传统技术栈存在的问题尚没有那么明显，整体业务只需要不到 10 台服务器就足以支撑，基础设施费用还是可以承受的。随着用户体量的不断增大，尤其是海外用户的快速增长，即使服务器规模迅速扩展至数千台，依然很难平稳度过每日的流量高峰，由于服务端渲染属于计算密集型任务，对 CPU 资源需求非常高，每日高峰时段的任务数波动又比较大，经常出现高峰时段渲染出图任务需要几十分钟甚至几小时的等待，这么长的等待时间对设计师来说是不可接受的，而更可怕是计算资源超过设计值集群雪崩导致所有执行中任务全部崩溃。而流量低谷时，大量服务器处于空转状态，资源并没有得到合理利用。

此外，躺平设计家整个研发团队擅长的是在垂直领域，比如 3D 图形以及图像处理等领域的研发，却不得不在非核心的方向，比如基础设施运维上投入大量精力和金钱，而且随着规模的持续增长，这部分成本是越来越高，导致软件研发成本也开始越来越不受控，摊薄了本该用在核心产品上的资源投入，当时整个研发团队陷入非常痛苦的状态，谢康在采访中调侃道：“当时与领先的互联网公司的技术代差恐怕有 5 到 10 年之久。”

最终，在即将失去垂直领域先发优势的压力下，面对着多种编程语言拼起来的庞大、臃肿的技术平台，整个团队最终咬牙决定“要革自己的命”，决定通过云平台打通底层技术栈，向云原生架构迁移，放下一直背负的包袱，注意力重新回归核心业务。

云原生演变

在决定迁移之后，整个团队对当时的云平台需求是比较清晰的。谢康表示，首先是稳定性，自建机房时期很难达到较高的稳定性，经常遇到各类网络和软硬件设施导致的问题；其次是整体系统弹性，需要在流量高峰时迅速扩容，流量低谷时进行资源回收以降低成本；最后是高性能，如前文所言，设计渲染对计算能力的要求较高，属于 CPU 密集型计算，而上述这些都是传统公司自建机房很难达到的。相比之下，自动化运维的便捷性和系统可灵活扩展的优先级则显得不那么迫切。

最终，经过多方考量和评估，整个团队在 2016 年开始基于 AWS 进行云原生改造(后整体迁移至阿里云)。

第一阶段：组织架构调整及微服务改造

1967 年，马尔文·康威提出康威定律, 用一句话概况就是：“设计系统的架构受制于产生这些设计的组织的沟通结构。”

按照康威定律的说法，组织结构一定会反映到系统架构上，而传统企业大都习惯了自上而下的驱动方式。因此，在进行微服务改造之前，躺平设计家对组织架构和人员均进行了调整。谢康表示，躺平设计家最初成立时大部分员工来自 AutoDesk，并入居然集团后又受其影响，最终这些体现在决策模式，组织结构上均与国内互联网企业有巨大差异。如果希望进行改造，就需要对组织架构先进行调整。

具体来说，躺平设计家整个技术团队在 3D 图形及图像处理等核心算法上有独特优势，因此重点保留了研发工程师，将不得不做且又不擅长的中间件和基础运维等工作交给阿里云，网络和机房整个团队基本在架构中消失，运维团队大幅缩减，而产品团队，算法团队、大数据团队，包括处理大规模实时计算的研发人员都在增加，并开始招募 ServiceStack 和 Docker 等云原生相关研发人员。

在组织架构调整基本完成后，团队开始进行微服务改造。此时，新的问题又出现了。

与大多数传统企业类似，躺平设计家的系统最初采用的也是单体架构模型，但是规模非常庞大，上百个服务糅合在一起，服务间的逻辑依赖异常复杂，如果上云前先在本地进行微服务改造，整个拆解过程想必既耗时又耗力，甚至可以说短期内根本不具可能性。谢康表示，当时，整个团队采取了非常激进的做法，通过 Service Mesh 将服务治理能力下沉到基础设施，这样就可以在不对系统进行深度改造的情况下将应用运行在云平台之上。之所以选择 Service Mesh，也是因为最初的技术栈基于 Scala 和 C++编写，不经深度改造其在云上很难良好运转且当时微服务支持方面也比较欠缺。随后，团队就可以在不影响业务正常运转的情况下对应用进行微服务划分和重构，整体运维和伸缩部署变得十分容易。谢康补充道，躺平设计家可能也是国内最早一批使用 Service Mesh 的公司。

在经过一段不太长的迁移之后，躺平设计家的所有核心业务已经全部运行在阿里云平台之上，并部分完成了微服务化改造。但是，严格来说，这一阶段的“硬搬上云”虽然通过上云享受到了云平台本身提供的弹性、可用性及强大的计算能力等优势，但总体价值提升还并不是非常明显。

不过，整个团队依旧按计划进行第二阶段改造，一是因为持续的云原生化已经成为企业的必选项，无论是公有云还是私有云，不借助云原生的赋能，当时的 Homestyler(后来才更名为躺平设计家)与主流互联网公司间的技术代差只会越来越大；二是自从进入互联网 2.0 时代，企业的规模化越来越重要，以当时的体量和产品迭代速度，如果不向云平台迁移，不通过快速转型打磨出爆款产品快速成长起来，将很快失去先发优势并且后续的生存压力也会非常大。

第二阶段：从上云到云原生

在第一阶段改造完接近尾声之际，躺平设计家马上开始了第二阶段的改造，就是系统的深度微服务化改造和集群的规模自动化及集群自动化治理和按需伸缩能力。谢康表示，第二阶段已经开始从单纯上云向云原生方向改造，价值也比较明显，改造完成后整体的交付速度和运维自动化能力均有大幅提升。

举例来说，云原生改造之前，躺平设计家的交付周期可能以季度为单位，如今的交付周期已经缩短至以周为单位，每两周还会进行大的功能升级。并能在流量高峰时，做到以分钟为单位计算集群扩展，高峰时间段也可以做到及时出（设计）图，这一点甚至超过了部分本地化软件，再也没发生大范围的计算停滞故障。

与其他互联网公司一样，躺平设计家也有着大量 Web 应用和微服务，这些都运行在阿里云容器服务（ACK）中。不过，谢康表示，不同的是，躺平设计家服务器更多运行着计算密集型任务，原来 IDC 机房中的大部分服务器都是 48 核，甚至 96 核的定制机型，类似的高配服务器多达几百台，而且长时间极限压榨服务器算力的运行方式也导致机器故障率非常高。在改造过程中，如果想对这样的系统进行大规模改造上云并不是一件容易的事情。整个团队与阿里云的架构师和技术专家们共同改造，多次克服两地协助诸多不便一起讨论制定方案，测试最终在阿里云上完美解决计算密集型任务上云的问题。目前，躺平设计家已经退役全部线下渲染服务器并迁入阿里云云主机和阿里云容器服务 ACK，实现应用服务层面的弹性伸缩，完美运行再也不用担心服务硬件设施故障导致的突然计算力雪崩，并能在用户提交任务时动态调整集群规模。

除了上述通过上云解决计算资源按需伸缩的问题，谢康也表示，Serverless 和 Service Mesh 在躺平设计家的运用也越来越广泛，随着云原生改造的持续进行，越来越多需要按需伸缩的计算节点被解耦出来，重构掉之前严重依赖状态和过程中频繁读写外援数据的问题后，这部分逻辑全部迁移到了 Serverless 的节点中，通过一系列 Trigger 触发。不仅让整个系统变得更加灵活，仅需支付运行期间费用的方式也非常经济。基于阿里云的 Istio on ACK 可以创建、管控以及观测微服务功能，并轻松实现负载均衡、服务间认证以及监控等能力。Service Mesh 的集群里则承载了几乎全部基础服务，躺平设计家的第二阶段改造其实是一个深度微服务化的过程，通过绞杀者模式逐步剥离原来一个个祖传的庞然大物，最终使每个逻辑服务组都能自由扩展并能在故障时优雅降级。

起初，团队也考虑过利用 OpenStack 自建私有云。但是不管私有云还是公有云，云集群管理都是由若干一系列独立而又相互关联的项目组成的，而每个项目又由若干个组件组成。这些组件相互合作，构建成了整个云生态。这其中有负责集群管理，负责网络管理，负责存储管理，还有负责镜像管理等。对当时的躺平设计家而言，整体复杂度过高，而且云研发的人才十分紧缺，即使愿意投入资金想招募到这方面合适的人才都不是一件容易的事情，因此最终还是决定与公有云厂商合作，借助公有云提供的基础设施和服务，自身则更专注于核心算法及业务研发。众所周知，Kubernetes 已经成为事实标准，躺平设计家使用阿里云容器服务（ACK） 之后， 成熟的容器和容器编排能让研发无视 IaaS 的复杂性，同时提供强大的配置和管理功能，极大简化研发的配置管理工作。

第三阶段：DevOps 实践及后续规划

目前，虽然第二阶段的改造还在持续进行中，躺平设计家的技术团队已经做好了下一步的技术规划。接下来，DevOps 推进、边缘计算和基于 Service Mesh/Serverless 的规模化计算力整合提升将是整个研发团队云原生实践的重要方向。谢康表示，目前在 DevOps 方面还有更进一步提升的可能，而原先基于公有云的通用方案也需要结合自身需求进行一些定制化改造。

简单来说，在 DevOps 方面，谢康提及首先要做到及时感知，可以及时察觉到系统每个节点上的运行状态；其次是可触达，通过技术手段对每个阶段出现的问题进行解决，而非简单的重启了事，核心链路上的每个环节都必须有自愈能力，保证系统面临重大故障时可以通过熔断或者降级解决，避免全局瘫痪；最后是智能化运维，通过机器学习的方式根据历史数据对系统的整体健康情况进行把控，利用运维 AI 算法实现自动化，最终走向无值守运维。

此外，随着云原生越来越规范化，在高度自动化的 CI/CD 和边缘计算方面也开始有所突破，这些同样是躺平设计家的关注方向。谢康解释道，目前公司主打的是云端能力，但其实躺平设计家的整个用户交互非常频繁，过程中产生的流量也比较大。如果能将部分用户行为放到边缘网络节点而非全部集中到云端节点处理就能大幅提高用户体验，如果边缘计算上可以取得突破，将会对解决这个问题有非常大的改善，因此整个团队对该领域的发展密切关注。

实践效果

除了上文提及到的交互周期缩短，性能增强外，整个过程也让躺平设计家的用户数有了极大地提升。总结下来，谢康认为可以概括为如下四点：

1、基础设施费用减半，在规模扩大的基础上，在基础设施上的投入还缩减了近 50%；

2、研发成本降低，整个团队 50%以上的人员为研发和产品，在基础设施交付给阿里云之后，整个团队可以集中精力进行核心业务研发，交付速度大幅提升；

3、系统可用性提高到 99.96%，在人员及成本缩减的情况下，整体可用性却有了很大提升。

4、安全性提高，原来受限于整体架构，在达到 99%之后，小数点之后的每一次提高的成本都是非线性的，而通过云原生改造，可以用相对经济的方式达到较高安全度。

结束语

回顾整个过程，这场改造绝非易事。谢康表示，躺平设计家至少是幸运的，可以在短时间内迅速确定改造计划并实践成功。对于希望进行云原生改造的企业，谢康建议一定要做好相关技术储备和接受刮骨疗伤的心理准备，不要幻想不做任何工作就能实现平滑迁移，这不可能实现，技术改造必不可少。

其次，虽然云原生相关规范及组件逐渐成熟，但对传统企业而言，门槛依旧很高，如果迫切希望提升技术能力，组织内部要对架构调整达成共识，整个研发体系也需要做好充足的准备，决不能觉得托付给云厂商后就可以坐享其成，就能一步上云。整个上云的过程，决策者时刻都要做好迎接变化的准备。

最后，如上文所言，传统企业的决策链路通常是自上而下的形式，因此需要进行一次互联网化改造，不仅仅是研发层面，整个公司的管理人员都需要做好知识升级和观念更新，这也是躺平设计家在过去几年的上云之路所经历的。

嘉宾介绍：

谢康，从业互联网十几年的资深技术老鸟，曾先后供职于盛大，携程和同程艺龙，专注于大规模高可用的互联网架构设计和云原生的落地探索，拥有多年的平台架构经验，曾设计实现承载上万服务的微服务和 DevOps 平台。现就职于躺平设计家，主要负责整体技术架构和云原生推进工作。

相关文章：

《阿里巴巴云原生架构实践及热议技术解析》

《腾讯云原生战略及 Serverless 平台实践解析》

《青云 QingCloud 云原生实践：基于 KubeSphere 的 QKE 正式交付》