早年间云计算刚起步的时候，Infrastructure as a Service 概念兴起，基础设施即服务，各大云计算服务来支撑各个企业的业务发展。同样的道理，基础架构在公司内部相当于技术底座，对各个业务进行赋能，其重要性不言而喻。
贺晋如博士在回国之前，曾在 Facebook，Pinterest 工作过，后回国加入茄子快传，小红书。在国外的工作经历中有些收获对于现在的工作很有帮助的。用贺晋如自己的话说，分为两方面，第一方面是技术上，他曾经非常有幸和一些世界上很优秀的工程师一起工作，一起从 0 搭建大规模的分布式系统。这里的收获不仅仅是如何搭建各种系统，更多是跟这些大师学到的搭建复杂系统的思维体系，比如：如何在设计复杂系统时做各种架构上的取舍：如何写高质量的代码；如何有效的定位线上故障并及时排障。这些收获是让他在后面很长时间都有所收益。
第二方面是在工程师文化上，在 Facebook 的时候，公司鼓励工程师去不断尝试，不设限的去参与解决各种问题。
这些技术上和文化上的收获其实都在回国后的工作里起到了比较大的帮助，这些帮助也潜移默化的影响着他的工作。目前，贺晋如是小红书基础架构负责人，负责公司的云原生架构，高可用的服务架构，数据库，缓存和 NoSQL 存储系统。以下是对贺晋如的采访整理。
InfoQ：您的工作内容基本上是围绕基础架构领域，可以介绍一下您现在在小红书带领基础架构部门具体做哪些事情么？
贺晋如：小红书的基础架构主要包括数据库缓存，存储，中间件，Kubernetes 云原生计算等相关内容。
中间件系统的完整是随着业务的需要而慢慢建立起来的，当这些系统成体系，完善后，威力巨大。也许这就是坚持长期主义，相信技术的力量，允许犯错，提供平台的结果。
我们之前在中间件的迭代上碰到过很多问题，总的来说，最核心的点在于如何让中间件的升级迭代成本变低。举个例子，我们曾经对中间件版本做了一次比较大的升级操作，对流量进行精细化的控制。出发点是好的，要求业务方去设置这些参数，让服务更加的高可用。但事实上，在我们推动升级的过程中，一部分用户其实并不关注这些配置项，另外一些用户关注但不知道如何配置。业务方不愿意升级，得一个一个业务去做宣传或者帮他们升级。
拿到这些反馈后，我们意识到，需要做到让业务方的改动尽量的少，才能使推广新版本的成本足够的低。所以我们在后续的中间件迭代里就秉持了一个理念：中间件的升级需要尽量做到业务无感知，让业务方接入成本足够的低；任何一次版本的变动都需要做到足够的向下兼容。为此，我们开始在后续的版本着手施行无感知升级的方案，这样中间件的升级迭代的成本就下来了。
InfoQ：你们在招聘网站上对存储方面的候选人要求，对 Redis、MySQL 等数据库相关产品内核优化；缓存、数据库中间件性能优化、功能迭代；其他分布式数据库解决方案预研。想了解，你们现在的数据存储方案有哪些？对于存储有怎样的特殊需求？有哪些解决方案？
贺晋如：我们现在数据大部分都存放在自建的 MySQL 和 MongoDB 里，同时缓存使用的是自建的 Redis。这里值得一提的是，小红书的 Redis 集群在 2018 年就已经实现全部容器化在 Kubernetes 上部署了，应该算业界比较早尝试做存储容器化的公司。4 月份的 ArchSummit 全球架构师峰会上，我们缓存团队的同学也会和大家分享这方面的经验。在存储方面，我们自建了高性能的 KV 存储，这部分在去年的 QCon 已经做了分享。
随着小红书业务的不断成长，缓存集群的规模也在扩大，现有的集群方案已经不能满足要求了。我们目前正在进行缓存架构上的迭代，包括对缓存内核的优化，对节点探活机制的改进等等，力求满足超大规模缓存集群的要求。
目前存储的拼图还相对比较薄弱：除了 KV 存储以外，我们还有类似于 Facebook TAO 的一跳图查询引擎。但其实业务对我们的需求是很多的：包括支持复杂图查询的图数据库；表格存储；强一致的 KV 存储，时序数据的存储引擎；对象存储和块存储。这些都需要我们慢慢补齐。此外，随着业务的增长，我们也在探索基于持久化内存的 KV 存储。
InfoQ：MySQL、MongoDB、TiDB 等数据库产品在你们内部的选用，有哪些考量因素？如何配合业务需求？
贺晋如：主要考量因素是业务的需求和可扩展性，以及我们目前数据库团队的规模。我们会更倾向于使用更加主流的产品来作为我们存储核心数据的方案。因为 MySQL 在高可用，数据复制方面都有比 MongoDB 更加成熟的方案，也更容易运维。
InfoQ：异地多活等高可用建设上，具体是怎么做的，技术上攻克了哪些难点？现在处于什么阶段？
贺晋如：我们目前正在从单云架构向着多云架构演进。多云架构和传统的单云架构一个很大不同点是，在多云的环境里，我们让自己的技术栈做到云独立，同样的业务代码在任何一朵云上都可以跑得通。
这里主要的难点就是，服务间在跨云环境里的上下游调用，根据业务需求的不同，有的服务调用可以跨云，有的服务调用是需要做到严格限制在单元内的。新的服务发现逻辑如何做到在所有中间件版本和 mesh 数据面上都能适用，是我们当时在做多活时候的一个难点。
做多云多机房架构的本质是服务的高可用能力，在一个机房的服务发生故障时迅速将流量切走。这是我们面临的另一个难点。
目前小红书主要的技术改造集中在微服务访问的单元化改造，数据库存储层的异地多活改造，南北流量接入层网关改造。我相信这些都是做异地多活的团队都碰到并且需要去解决的一些问题。
在流量控制方面，我觉得很重要一点是在某个机房的下游服务发生故障时，故障的爆炸半径要做到足够的小，尽可能的控制在单机房内。
举一个在实际生产中碰到的例子，在我们 SDK 设计里，流量控制参考了 mesh 的实现：默认上下游服务调用都在单机房内完成。在同机房下游服务健康实例不足的时候会自动 failover 一部分流量到另一个机房。这个设计的初衷是，在同机房下游服务出现容量不足时，能自动的把一部分流量切到另一个机房来保证上下游服务调用的正常。看上去是很合理的，但是在实际中碰到的情况是：上游服务因为流量过载把同机房内的下游服务实例打垮，上游流量会自动的 failover 到另外机房的下游服务，另一个机房的下游服务由于短时间内承接了之前 2X 的流量，很快也挂了，导致我们整条链路宕机。如果没有自动的跨机房流量跳转，我们是可以把故障控制在单机房内。从而保证另外一个机房的流量是正常的。
InfoQ：对于先进的架构和理念选择上，你们有哪些考量和标准？
贺晋如：我觉得核心考量的标准是这些新的架构和理念是否能够为我们的业务赋能，是否能为我们的研发工程师提效降本，是否能提高我们整体架构的稳定性。任何脱离了实际业务来谈架构和理念都是没有意义的。
在这个基础上，架构的通用性和普适性也是我们考虑的因素。这套架构是否已经在相同规模或者更大规模的互联网公司落地。是否已经带来了好的收益。同时一套通用的架构也更容易让我们在市场上招到匹配的人才。
架构的灵活性能给我们足够的可扩展空间进行二次开发来满足业务的需求。我们的业务是一直在高速发展的，如果一套架构不具有可扩展性，那么有可能会在某个阶段成为业务进一步发展的卡点。
InfoQ：在架构上，不管是设计层面，还是应用层面，您这两年有哪些发现，或者观察？对软件架构的发展，有哪些预测，或者期待？
贺晋如：微服务的 Serverless 化，由架构团队来负责容器，云等底层资源管理，屏蔽底层资源差异性，向业务提供可靠、稳定、可弹性的运行环境，让业务技术团队能聚焦业务需求的快速迭代。
另外，把有状态服务容器化上 Kubernetes。数据库，存储容器化后，有进一步的空间可以提升存储集群的资源利用率。并且也可以减少运维人员的一些重复性工作。
嘉宾介绍：贺晋如 博士
小红书基础架构负责人，拥有十余年高性能分布式系统，微服务高可用架构工作经验，先后在 Facebook，Pinterest 参与和主导大规模分布式图数据库，NoSQL 存储系统，机器学习推理平台等项目的设计和研发。目前在小红书负责公司的云原生架构，高可用的服务架构，数据库，缓存和 NoSQL 存储系统。
除了上面的回复内容外，贺晋如老师还会出席 4 月下旬在上海举办的 ArchSummit 全球架构师峰会活动，他是“架构系统性能优化”专题出品人，这个专题下邀请了小红书、字节跳动、阿里巴巴的技术专家来分享各自的实践内容，感兴趣的可以关注会议日程。
,
