系统架构图素材-基于Spring+SpringMVC+Mybatis分布式敏捷开发系统架构（附源码）

原创：素材网 2023-03-15 06:29:21

微服务改造―架构设计

博客原文

至于为什么构建微服务架构的系统设计，如何构建微服务架构，这些问题有很多文章介绍，我自己也有一篇文章介绍相关话题，感兴趣的同学可以翻看。

本文的主题思想是，介绍一下如何在进行微服务改造的初始阶段构建一个完美的目标架构，未来的一切改造动作都向着这个目标靠近，目标架构对我们进行的微服务改造实施起到一个指引的作用。

本文的素材来源是我厂的微服务改造目标架构产生的过程，记录下这个难忘又烧脑的过程，写完之后有可能就是一个流水账。希望微服务改造完成之后再看这篇文章时，发现开始的这些架构设计都落地了，简直就完美啦！！！

本次讨论会的成员来自技术部门的架构组和各个业务能力开发组的主要开发人员，同时也邀请了华为的软件专家现场指导。从参与人员上来看，既有能够总览公司当前现状的架构师，也有开发经验开发的一线开发人员（覆盖多数的业务场景），在每个人的心中都有一个美好的愿景，大家的思想互相碰撞融合，吸收各自的优秀方案，最后形成了一个相对完善的目标架构。

微服务改造是一个漫长的过程，看过一些公司的改造历程，类似规模的系统改造下来需耗时2年左右。因此，为了保证整个微服务改造过程能够有条不紊的进行，必需一个可落地实施的规划。我们的计划如下：

看起来这是一个相对稳妥的计划，经过这样一个微服务的改造过程之后，我们的所有业务系统结构更加合理，互相之间的耦合度降低，明确的业务边界，依赖关系接近一个从上到下的树形结构。

我们是一家第三方支付公司，同学们应该很容易能够想象到一个大致的业务系统范围，以及内部的系统组成架构。我们在网上也能够看到各大第三方支付公司的系统架构图，我们虽然是一家小的支付公司，但是麻雀虽小五脏俱全，应有尽有。只是由于在发展初期都是业务驱动，涌现出了很多系统，很多都是独立建设的，难免系统建设的有些臃肿，很多系统之间存在大量不合理的调用，画出调用关系图来看，显得非常凌乱。并且很多功能重复建设，浪费资源。

目前的这个架构中，有一部分系统是已经经过了重构的，但是这些重构也是相对的独立的进行的，而且没有统一的规范。重构系统的设计完全取决于主要设计人员的知识视野，以及他对业务的理解。在技术选型上也是各有不同，一般选择相对熟悉并且把握比较大框架。每个系统在架构设计上也各有不同，最近建设的几个系统基本都是采用了微服务设计模式，也有采用SOA架构的，也有仅仅是做了前后分离设计的系统，完全是单体结构的项目也有存在。

虽然我们开始对系统建设有一定的规划，但是随着业务的快速野蛮发展，一味地追求快，迁就于业务设计。这样结果就是，不论是重构和改造的系统，还是新建的系统所包含的业务边界不明显，互相之间都存在重复的功能被开发，相对比较零散，建造系统的时候没有一种浑然天成的感觉。

这样的现状引发的问题主要有：

借着微服务架构的设计思想，指导我们进行系统改造。将基础服务从各个业务系统中剥离，形成统一服务能力；各种支撑系统实现高性能、高可用的基础设施逐渐完善；让业务系统能够更加专注于业务逻辑实现。利用领域驱动设计的指导思想，划清各系统的业务边界。经过这样的一番规划和设计之后，应该能够实现系统架构的完美升级。

微服务架构只是在概念上给我们指明了方向，制定了几个重要的设计原则：

服务尽可能小、可独立部署、自动化部署和运维

。这些概念需要在落地实施，由于理解上的差异以及公司的现状各式各样，每个公司实施下来肯定各有不同，都是每个公司自己特色的微服务架构，毕竟架构设计是服务于业务模块的。所以我厂也在讨论符合我们自己公司特色的微服务架构如何实施。

在讨论的过程中有几个争论的话题，在这里总结一下：

其实前面两点说的都是业务边界划分的问题，第一点是分层之后的纵向边界，第二点是横向边界。针对第一点，我们拿充值功能举例：

标准的充值流程是1. 用户银行卡上扣钱（支付接口）；2. 用户内部账户记账。详细的步骤这里没有说明，熟悉支付业务的同学应该了解，支付有多种支付方式，内部账户也有多种（标准充值上账是用户的现金账户）。若是标准的充值，这两步分别走的也是标准流程；若是有特殊的业务，充值是充到佣金账户，这样的特定业务的充值是否要放到充值中心实现？在第三方支付公司待久了会发现，有各种标准产品，也有很多定制化的产品。

我们的结论是：标准化的功能，由底层服务为产品层提供标准能力支撑，具有强烈的个别业务特性化的功能，由产品层直接调用更底层的能力自己封装实现。

就第二点而言，可能有些同学会疑惑，微服务架构的原则不是将服务拆分的尽可能小，实现高内聚、低耦合吗？为什么还有合并呢？我的理解是，这个原则只是适用于完全的业务逻辑设计，在系统建设中也有一些基本业务无关的组件要实现，这些公共服务（如，统一流水号、统一session管理等）应该抽象出来统一实现，被业务系统调用。还有一些在管理方式和用途上都很类似的数据，这些数据可放在一起管理，统一提供服务。

在做业务设计时，微服务的设计原则是避免单点模块，完全分布式、高内聚的服务好处很多，压力分散，互相之间影响较小，但是它们需要各自管理。其实这些好处都是相对的，在一个技术平均水平较高的公司里，内聚的系统相对较好，各种技术都能驾驭的很好。比如，支付订单系统是否要分散到各个产品系统中，还是统一做一个订单中心，这样在需要提高性能的时候，需要做一些异步化处理的时候，都能统一在一处实现性能提高。

在Martin Fowler对微服务的论证中能够看到，微服务架构不仅仅是系统架构，也是人员组织架构的指导。团队要尽可能的全栈，实现高内聚、低耦合。为了减少部门组织交叉协作带来的低效，我们负责的是一个个产品，不是一个交付了就完事的项目，产品的整个生命周期都应该由这个团队维护。这样的话，原来的组织结构在微服务改造的实施下也需要做出调整，这是需要领导的支持力度的。

在支撑系统和基础设施上，没有太多的讨论，这套底层运维服务相对比较标准，而且大部分已经建设完成，目前处于完善和优化的阶段。

总结一下，架构设计本身就是一门博弈权衡的学问，无论是现在流行的微服务架构还是之前的SOA等其它架构，都无例外。最好的架构设计是要适合公司本身的业务发展和规划，以及组织结构，目前的这些可能会阻碍微服务化的进程，但是从实际出发，这些业务和组织能够为微服务化做出多大的改变，也是需要考虑的问题。我们不是在做大刀阔斧的改革，微服务化改造应该是一个水到渠成的、循序渐进的优化过程。

第一次参与这么大范围的架构设计，发现需要权衡的东西太多了，有些设计原则是否需要坚持。

最终我根据大家讨论达成的共识，以及自己对业务的理解，做出了下面的架构设计图：

阿里IM技术分享(六)：闲鱼亿级IM消息系统的离线推送到达率优化

本文由阿里闲鱼技术团队逸昂分享，原题“消息链路优化之弱感知链路优化”，有修订和改动，感谢作者的分享。

闲鱼的IM消息系统作为买家与卖家的沟通工具，增进理解、促进信任，对闲鱼的商品成交有重要的价值，是提升用户体验最关键的环节。

然而，随着业务体量的快速增长，当前这套消息系统正面临着诸多急待解决的问题。

以下几个问题典型最为典型：

1）在线消息的体验提升；

2）离线推送的到达率；

3）消息玩法与消息底层系统的耦合过强。

经过评估，我们认为现阶段离线推送的到达率问题最为关键，对用户体验影响较大。

本文将要分享的是闲鱼IM消息在解决离线推送的到达率方面的技术实践，内容包括问题分析和技术优化思路等，希望能带给你启发。

（本文已同步发布于：）

本文是系列文章的第6篇，总目录如下：

《阿里IM技术分享(一)：企业级IM王者――钉钉在后端架构上的过人之处》

《阿里IM技术分享(二)：闲鱼IM基于Flutter的移动端跨端改造实践》

《阿里IM技术分享(三)：闲鱼亿级IM消息系统的架构演进之路》

《阿里IM技术分享(四)：闲鱼亿级IM消息系统的可靠投递优化实践》

《阿里IM技术分享(五)：闲鱼亿级IM消息系统的及时性优化实践》

《阿里IM技术分享(六)：闲鱼亿级IM消息系统的离线推送到达率优化》（* 本文）

从数据通信链接的技术角度，我们根据闲鱼客户端是否在线，将整体消息链路大致分为强感知链路和弱感知链路。

强感知链路由以下子系统或模块：

1）发送方客户端；

2） idleapi-message（闲鱼的消息网关）；

3） heracles（闲鱼的消息底层服务）；

4） accs（阿里自研的长连接通道）；

5）接收方客户端组成。

整条链路的核心指标在于端到端延迟和消息到达率。

强感知链路中的双方都是在线的，消息到达客户端就可以保证接收方感知到。强感知链路的主要痛点在消息的端到端延迟。

弱感知链路与强感知链路的主要不同在于：弱感知链路的接收方是离线的，需要依赖离线推送这样的方式送达。

因此弱感知链路的用户感知度不强，其核心指标在于消息的到达率，而非延迟。

所以当前阶段，优化弱感知链路的重点也就是提升离线消息的到达率。换句话说，提升离线消息到达率问题，也就是优化弱感知链路本身。

下图一张整个IM消息系统的架构图，感受下整体链路：

如上图所示，各主要组件和子系统分工如下：

1） HSF是一个远程服务框架，是dubbo的内部版本；

2） tair是阿里自研的分布式缓存框架，支持 memcached、Redis、LevelDB 等不同存储引擎；

3） agoo是阿里的离线推送中台，负责整合不同厂商的离线推送通道，向集团用户提供一个统一的离线推送服务；

4） accs是阿里自研的长连接通道，为客户端、服务端的实时双向交互提供便利；

5） lindorm是阿里自研的NoSQL产品，与HBase有异曲同工之妙；

6）域环是闲鱼消息优化性能的核心结构，用来存储用户最新的若干条消息。

强感知链路和弱感知链路在通道选择上是不同的：

1）强感知链路使用accs这个在线通道；

2）弱感知链路使用agoo这个离线通道。

通俗了说，弱感知链路指的就是离线消息推送系统。

相比较于在线消息和端内推送（也就是上面说的强感知链路），离线推送难以确保被用户感知到。

典型的情况包括：

1）未发送到用户设备：即推送未送达用户设备，这种情况可以从通道的返回分析；

2）发送到用户设备但没有展示到系统通知栏：闲鱼曾遇到通道返回成功，但是用户未看到推送的案例；

3）展示到通知栏，并被系统折叠：不同安卓厂商对推送的折叠策略不同，被折叠后，需用户主动展开才能看到内容，触达效果明显变差；

4）展示到通知栏，并被用户忽略：离线推送的点击率相比于在线推送更低。

针对“1）未发送到用户设备”，原因有：

1）离线通道的token失效；

2）参数错误；

3）用户关闭应用通知；

4）用户已卸载等。

针对“3）展示到通知栏，并被系统折叠”，原因有：

1）通知的点击率；

2）应用在厂商处的权重；

3）推送的数量等。

针对“4）展示到通知栏，并被用户忽略”，原因有：

1）用户不愿意查看推送；

2）用户看到了推送，但是对内容不感兴趣；

3）用户在忙别的事，无暇处理。

总之：以上这些离线消息推送场景，对于用户来说感知度不高，我们也便称之为弱感知链路。

我们的弱感知链路分为3部分，即：

1）系统；

2）通道；

3）用户。

共包含了Hermes、agoo、厂商、设备、用户、承接页这几个环节。具体如下图所示。

从推送的产生到用户最终进入APP，共分为如下几个步骤：

步骤1 ：Hermes是闲鱼的用户触达系统，负责人群管理、内容管理、时机把控，是整个弱感知链路的起点。；

步骤2 ：agoo是阿里内部承接离线推送的中台，是闲鱼离线推送能力的基础；

步骤3 ：agoo实现离线推送依靠的是厂商的推送通道（如：苹果的 apns通道、Google的fcm通道、及国内各厂商的自建通道。；

步骤4 ：通过厂商的通道，推送最终出现在用户的设备上，这是用户能感知到推送的前提条件；

步骤5 ：如果用户刚巧看到这条推送，推送的内容也很有趣，在用户的主动点击下会唤起APP，打开承接页，进而给用户展示个性化的商品。

经过以上5个步骤，至此弱感知链路就完成了使命。

弱感知链路的核心问题在于：

1）推送的消息是否投递给了用户；

2）已投递到的消息用户是否有感知。

这对应推送的两个阶段：

1）推送消息是否已到达设备；

2）用户是否查看推送并点击。

其中：到达设备这个阶段是最基础的，也是本次优化的核心。

我们可以将每一步的消息处理量依次平铺，展开为一张漏斗图，从而直观的查看链路的瓶颈。

漏斗图斜率最大的地方是优化的重点，差异小的地方不需要优化：

通过分析以上漏斗图，弱感知链路的优化重点在三个方面：

1） agoo受理率：是指我们发送推送请到的数量到可以通过agoo（阿里承接离线推送的中台）转发到厂商通道的数量之间的漏斗；

2）厂商受理率：是指agoo中台受理的量到厂商返回成功的量之间的漏斗；

3） Push点击率：也就通过以上通道最终已送到到用户终端的消息，是否最终转化为用户的主动“点击”。

有了优化方向，我们来看看优化手段吧。

跟随推送的视角，顺着链路看一下我们是如何进行优化的。

用户的推送，从 Hermes 站点搭乘“班车”，驶向下一站： agoo 。

这是推送经历的第一站。到站一看，傻眼了，只有不到一半的推送到站下车了。这是咋回事嘞？

这就要先说说 agoo 了，调用 agoo 有两种方式：

1）指定设备和客户端，agoo直接将推送投递到相应的设备；

2）指定用户和客户端，agoo根据内部的转换表，找到用户对应的设备，再进行投递。

我们的系统不保存用户的设备信息。因此，是按照用户来调用agoo的。

同时：由于没有用户的设备信息，并不知道用户是 iOS 客户端还是 Android 客户端。工程侧不得不向 iOS 和 Android 都发送一遍推送。虽然保证了到达，但是，一半的调用都是无效的。

为了解这个问题：我们使用了agoo的设备信息。将用户转换设备这一阶段提前到了调用 agoo 之前，先明确用户对应的设备，再指定设备调用 agoo，从而避免无效调用。

agoo调用方式优化后，立刻剔除了无效调用，agoo受理率有了明显提升。

至此：我们总算能对 agoo 受理失败的真正原因做一个高大上的分析了。

根据统计：推送被 agoo 拒绝的主要原因是――用户关闭了通知权限。同时，我们对 agoo 调用数据的进一步分析发现――有部分用户找不到对应的设备。优化到此，我们猛然发现多了两个问题。

那就继续优化呗：

1）通知体验优化，引导打开通知权限；

2）与agoo共建设备库，解决设备转换失败的问题。

这两个优化方向又是一片新天地，我们择日再聊。

推送到达 agoo ，分机型搭乘厂商“专列”，驶向下一站：用户设备。

这是推送经历的第二站。出站查票，发现竟然超员了。

于是乎：我们每天有大量推送因为超过厂商设定的限额被拦截。

为什么会这样呢？

实际上：提供推送通道的厂商（没错，各手机厂商的自家推送通道良莠不齐），为了保证用户体验，会对每个应用能够推送的消息总量进行限制。

对于厂商而言，这个限制会根据推送的类型和应用的用户规模设定――推送主要分为产品类的推送和营销类的推送。

厂商推送通道对于不同类型消息的限制是：

1）对于产品类推送，厂商会保证到达；

2）对于营销类推送，厂商会进行额度限制；

3）未标记的推送，默认作为营销类推送对待。

我们刚好没有对推送进行标记，因此触发了厂商的推送限制。

这对我们的用户来说，会带来困扰。闲鱼的交易，很依赖买卖家之间的消息互动。这部分消息是需要确保到达的。

同样：订单类的消息、用户的关注，也需要保证推送给用户。

根据主流厂商的接口协议，我们将推送的消息分为以下几类，并进行相应标记：

1）即时通讯消息；

2）订单状态变化；

3）用户关注内容；

4）营销消息这几类。

同时，在业务上，我们也进行了推送的治理――将用户关注度不高的消息，取消推送，避免打扰。

经过这些优化，因为超过厂商限额而被拦截的推送实现了清零。

通过优化agoo受理率、厂商受理率，我们解决了推送到达量的瓶颈。但即使消息被最终送达，用户到底点击了没有？这才是消息推送的根本意义所在。

于是，在日常的开发测试过程中，我们发现了推送的两个体验问题：

1）用户点击Push有开屏广告；

2）营销Push也有权限校验，更换用户登陆后无法点击。

对于开屏广告功能，我们增加了Push点击跳过广告的能力。

针对Push的权限校验功能，闲鱼根据场景做了细分：

1）涉及个人隐私的推送，保持权限校验不变；

2）营销类的推送，放开权限校验。

以上是点击体验的优化，我们还需要考虑用户的点击意愿。

用户点击量与推送的曝光量、推送素材的有趣程度相关。推送的曝光量又和推送的到达量、推送的到达时机有关。

具体的优化手段是：

1）在推送内容上：我们需要优化的是推送的时机和相应的素材；

2）在推送时机上：算法会根据用户的偏好和个性化行为数据，计算每个用户的个性化推送时间，在用户空闲的时间推送（避免在不合适的时间打扰用户，同时也能提升用户看到推送的可能性）。

3）在推送素材上：算法会根据素材的实时点击反馈，对素材做实时赛马。只发用户感兴趣的素材，提高用户点击意愿。

通过以上我们的分析和技术优化手段，整体弱推送链路链路有了不错的提升，离线消息的到达率相对提升了两位数。

本篇主要和大家聊的是只是IM消息系统链路中的一环――弱感知链路的优化，落地到到具体的业务也就是离线消息送达率问题。

整体IM消息系统，还是一个比较复杂的领域。

我们在消息系统的发展过程中，面临着如下问题：

1）如何进行消息的链路追踪；

2）如何保证IM消息的快速到达（见《闲鱼亿级IM消息系统的及时性优化实践》)；

3）如何将消息的玩法和底层能力分离；

4）离线推送中如何通过用户找到对应的设备。

这些问题，我们在以前的文章中有所分享，以后也会陆续分享更多，敬请期待。

[1] Android P正式版即将到来：后台应用保活、消息推送的真正噩梦

[2] 一套高可用、易伸缩、高并发的IM群聊、单聊架构方案设计实践

[3] 一套亿级用户的IM架构技术干货(上篇)：整体架构、服务拆分等

[4] 一套亿级用户的IM架构技术干货(下篇)：可靠性、有序性、弱网优化等

[5] 从新手到专家：如何设计一套亿级消息量的分布式IM系统

[6] 企业微信的IM架构设计揭秘：消息模型、万人群、已读回执、消息撤回等

[7] 融云技术分享：全面揭秘亿级IM消息的可靠投递机制

[8] 移动端IM中大规模群消息的推送如何保证效率、实时性？

[9] 现代IM系统中聊天消息的同步和存储方案探讨

[10] 新手入门一篇就够：从零开发移动端IM

[11] 移动端IM开发者必读(一)：通俗易懂，理解移动网络的“弱”和“慢”

[12] 移动端IM开发者必读(二)：史上最全移动弱网络优化方法总结

[13] IM消息送达保证机制实现(一)：保证在线实时消息的可靠投递

[14] IM消息送达保证机制实现(二)：保证离线消息的可靠投递

[15] 零基础IM开发入门(一)：什么是IM系统？

[16] 零基础IM开发入门(二)：什么是IM系统的实时性？

[17] 零基础IM开发入门(三)：什么是IM系统的可靠性？

[18] 零基础IM开发入门(四)：什么是IM系统的消息时序一致性？

（本文已同步发布于：）