知乎服务化的实践与思考.docxVIP

知乎服务化的实践与思考 「微服务」 是业内最近两三年业内很火的 buzzword，迁移到微服务架构，大多强调这些好处： 松耦合 独立发布 快速迭代 毛病隔离 添加重用 经过服务的拆分，将简单到难以移动的单体应用，拆分为多个可以独立部署的服务，单个服务的简单性远远小于全体，这样不同服务的开发者可以并行开发，从而提高开发效率；由于服务的细粒度，可以 assign 给一个具体的人让他担任，随着业务的增长对服务做定向扩容；同时由于服务的隔离性，可以隔离毛病，提高全体的稳定性。不过在推动服务化的过程中，也感遭到一些不测的痛点。我们首先感遭到的是服务数量的不行控。新 feature 经常会以新服务的方式开头开发，而非扩呈现有的服务。随着产品的需求迭代，服务越来越碎片化，扩呈现有服务变得越来越困难，由于很难选择加入到哪个服务更好。而且扩展一个其他人担任的服务，沟通成本不能忽视，这时出于产品进度的压力，另起炉灶开头一个新服务实在是最快的选择。其次，部分业务基于 RPC 做水平分拆，准绳上 RPC 的演进要保持向前兼容，而项目前期需求不稳定阶段，难免引进相当多的 break change，发包、上线、联调成本居高不下，也引进了额外的发布风险：上层服务和下层服务两者务必同时发布，但不能回滚其中之一。这在重要的功能开发中，成为了我们快速迭代的一个绊脚石。拆分为 RPC 之后，通信介质发生了不同，而访问模式的顺应不肯定预备好。对有缓存掩盖的数据访问对象而言，N+1 式的访问模式不算问题，但是 N+1 query 对 RPC 却不能接受。服务的调用压力经常出乎维护者的意料，RPC 放大使得下层服务的波动放大，风险添加之余也添加了对资源的需求，而资源占用更多的同时，功能仍远低于过去对缓存的访问。 基于 SSO 的分拆 RPC （近程过程调用）是服务化体系中基础的基础，但是渐渐的我们发觉 RPC 并非分拆的独一选择。基于 RPC 的水平分拆会引入两头层次，添加联调的环节，对于快速开发的新业务而言，无法忽视额外的联调成本。联调中发觉问题时不得不在各个层次定位，难以自动化测试。经过今年几个快速迭代的新项目从主站的分拆，我们发觉基于 SSO （单点登录）机制对 HTTP 接口做垂直拆分是一条可行的路，可灰度把握风险、对客户端透亮?????。新项目对主站的耦合往往较低，只需要 get_member 等少量几个 RPC 接口，对外暴露的接口也格外少。新项目的迭代速度快，经过拆分，能够使服务与后端团队的完整业务相婚配，降低了主站联动的发布频率，某种程度上也削减了出于部署积压而积累的发布风险。这里我们得到的启发是，服务的分拆并非 RPC 不行。相反，我们期望看到更少的 RPC，更多的内聚。更少的 RPC 接口意味着更小的服务边界，更稳定的接口，更少的 break change。内聚意味着允许功能需求的独立演进，对其他业务的影响降到最低，也意味着内聚的业务模块内部，可以充分利用缓存来优化功能。 桌面端怎样拆？ 新项目之所以拆分顺当，也得益于它们当前只面对客户端，HTTP API 的拆分仍较为简约。然而桌面端的情形有所不同，一个页面往往不能单纯对应到一个服务上，比如问答页，除了问答服务，还需要评论、保藏、内容推举等信息需要呈现，这些页面组件背后的服务会趋于不同的工程师或团队维护。这里可以留意到一件有意思的事情，在后端社区 buzzword 「服务化」 的同时，前端社区愈加如火如荼地 buzzword 着 「前后端分别」 和 「组件化」。出于内容呈现的简单性，页面并不能成为分拆的好单位，但页面内的组件无疑更简约与后端的功能模块相婚配。「服务化」 和 「组件化」 是一对孪生子，分别允许后端团队和前端团队去隔离业务模块、独立演进。知乎也正在进行着桌面端的前后端分别改造。随后桌面端不再特殊，允许后端面对 iOS / Android / Web 三端按同一套接口进行对接，也就可以像移动端 API 同样的方式，基于单点登录进行拆分了。 垂直拆分的风险 当前感遭到垂直拆分的次要风险在于保证不同垂直业务对同类型实体呈现规律的全都性。其中 feed 对这点要求最高，由于它对全部实体类型都有引用。为此在拆分 feed 流之前，先行补充了全部实体的 swagger 文档，通过中心的 swagger 文档约束住同一实体在不同服务中的字段呈现。 如何划分服务边界 抱负的世界里，服务边界恰好婚配于业务边界。然而工程师首先要担当业务需求的压力，只能抽时间重构拆分，业务边界也并不总是如新项目那样明晰。这意味着要考虑优先级，也需要在拆分之前认真地思考业务的边界。排定优先级，考量拆分的收益与风险即可。划分业务的边界，则需要更多的思考拆分后的将来将如何沟通协作，然后再考