朱晔的互联 网架构实践心得S1E2屡试不爽的架构三马车.docxVIP

最新整理资料 文档精选合集 朱晔的互联网架构实践心得 S1E2：屡试不爽的架构三马车 【下载本文 PDF 进行阅读】 这里所说的三架马车是指微服务、消息队列和定时任务。如下图所示，这里是一个三驾马车共同驱动的一个立体的互联网项目的架构。不管项目是大是小，这个架构模板的形态一旦定型了之后就不太会变，区别只是我们有更多的服务有更复杂的调用，更复杂的消息流转，更多的 Job，整个架构整体是可扩展的，而且不会变形，这个架构可以在很长的一段时间内无需有大的调整。 图上画了虚线框的都代表这个模块或项目是不包含太多业务逻辑的，纯粹是一层皮（会调用服务但是不会触碰数据库）。黑色线的箭头代表依赖关系，绿色和红色箭头分别是 MQ 的发送和订阅消息流的方向。具体在后文都会进一步详细说明。 微服务 微服务并不是一个很新的概念，在 10 年前的时候我就开始实践这个架构风格，在四个公司的项目中全面实现了微服务，越来越坚信这是非常适合互联网项目的一个架构风格。不是说我们的服务一定要跨物理机器进行远程调用，而是我们通过进行有意的设计让我们的业务在一开始的时候就按照领域进行分割，这能让我们对业务有更充分的理解，能让我们在之后的迭代中轻易在不同的业务模块上进行耕耘，能让我们的项目开发越来越轻松，轻松来源于几个方面： 如果我们能进行微服务化，那么我们一定事先经过比较完善的产品需求讨论和领域划分，每一个服务精心设计自己领域内的表结构，这是一个很重要的设计过程，也决定了整个技术架构和产品架构是匹配的，对于 All-In-One 的架构往往会省略这一过程， 需求到哪里代码写到哪里。 我们对服务的划分和指责的定位如果是清晰的，对于新的需求，我们就能知道需要在哪里改怎么样的代码，没有复制粘贴的存在少了很多坑。 我们大多数的业务逻辑已经开发完毕，直接重用即可，我们的新业务只是现有逻辑的聚合。在 PRD 评审后，开发得到的结论是只需要组合分别调用 ABC 三个服务的 XYZ 方法，然后在 C 服务中修改一下 Z 方法增加一个分支逻辑，就可以构建起新的逻辑， 这种爽快的感觉难以想象。 在性能存在明显瓶颈的时候，我们可以针对性地对某些服务增加更多机器进行扩容， 而且因为服务的划分，我们更清楚系统的瓶颈所在，从 10000 行代码定位到一行性能存在问题的代码是比较困难的，但是如果这 10000 行代码已经是由 10 个服务构成 的，那么先定位到某个服务存在性能问题然后再针对这个服务进行分析一下子降低了定位问题的复杂度。 如果业务有比较大的变动需要下线，那么我们可以肯定的是底层的公共服务是不会淘汰的，下线对应业务的聚合业务服务停掉流量入口，然后下线相关涉及到的基础服务进行部分接口即可。如果拥有完善的服务治理平台，整个操作甚至无需改动代码。 这里也要求我们做到几个方面的原则： 服务的粒度划分需要把控好。我的习惯是先按照领域来分不会错，随着项目的进展慢慢进行更细粒度的拆分。比如对于互联网金融 P2P 业务，一开始可以分为： 三方合作服务 PartnerInvestService：对接合作的三方理财平台的流量 普通投资服务 NormalInvestService：最普通形态的资产的主流程 预约投资产品服务 ReserveInvestService：需要预约投资的资产的主流程 周期性计划产品服务 AutoInvestService：会定期自动复投的理财产品主流程 投资人交易服务 TradeService：专门负责处理投资人的交易行为，比如投资 借款人交易服务 LoanService：专门负责处理借款人的交易行为，比如还款 用户服务 UserService：处理用户的注册登录等 资产服务 ProjectService：处理资产和标的相关 账户账务服务 AccountService：处理用户的账户各个子账户和账务记录 营销活动服务 ActivityService：处理各种活动、用户的积分体系 会员体系服务 VipService：处理用户的会员成长体系 银行存管服务 BankService：专门用于对接银行存管系统 电子签章服务 DigSignService：专门用于对接三方数字签章系统 消息推送服务 MessageService：专门用于对接三方短信通道和推送 SDK 服务一定是立体的，不是在一个层次上的，如上图，我们的服务有三个层次： 聚合业务服务：高层次的串起来整个流程的具有完整业务形态的业务服务。和基础业务服务不同的是，这里是在完整描述一方面的业务，这个业务往往是由各种基础业务拼装组合起来的。和不同外部合作方的不同合作形式，给用户提供的产品的不同服务形态，都决定了聚合业务服务会有业务流程上的差异化， 如果把此类服务下放到基础业务服务中，那么基础业务服务会有各种 if-else 逻辑（根