从 0 开始学架构
李运华
网名“华仔”,前阿里资深技术专家(P9)
152573 人已学习
新⼈⾸单¥68
登录后,你可以任选4讲全文学习
课程目录
已完结/共 66 讲
结束语 (1讲)
结课测试 (1讲)
从 0 开始学架构
15
15
1.0x
00:00/00:00
登录|注册

43 | 互联网架构模板:“用户层”和“业务层”技术

虚拟业务域的引入
分层架构、微服务、微内核
存储云和图片云的实现
文件上传和存储需求
消息推送的设备管理、连接管理和消息管理
Android消息推送的挑战
短信、邮件、站内信、App推送
用户管理系统架构
授权登录(OAuth 2.0)
单点登录(SSO)
子系统数量过多的问题
拆分解决复杂度问题
复杂度挑战
存储云、图片云
消息推送
用户管理
业务层技术
用户层技术
思考题:虚拟业务域划分的粒度需要粗一些还是要细一些?虚拟业务域的数量大概是多少,理由是什么?
互联网架构模板的“用户层”和“业务层”技术有哪些?

该思维导图由 AI 生成,仅供参考

上一期,我从计算机网络层的角度谈了应对“高性能”和“高可用”的整体架构设计。今天,我将从“用户层”和“业务层”的角度谈谈常见的应用场景和关键技术

用户层技术

1. 用户管理
互联网业务的一个典型特征就是通过互联网将众多分散的用户连接起来,因此用户管理是互联网业务必不可少的一部分。
稍微大一点的互联网业务,肯定会涉及多个子系统,这些子系统不可能每个都管理这么庞大的用户,由此引申出用户管理的第一个目标:单点登录(SSO),又叫统一登录。单点登录的技术实现手段较多,例如 cookie、JSONP、token 等,目前最成熟的开源单点登录方案当属 CAS,其架构如下(https://apereo.github.io/cas/4.2.x/planning/Architecture.html ):
除此之外,当业务做大成为了平台后,开放成为了促进业务进一步发展的手段,需要允许第三方应用接入,由此引申出用户管理的第二个目标:授权登录。现在最流行的授权登录就是 OAuth 2.0 协议,基本上已经成为了事实上的标准,如果要做开放平台,则最好用这个协议,私有协议漏洞多,第三方接入也麻烦。
用户管理系统面临的主要问题是用户数巨大,一般至少千万级,QQ、微信、支付宝这种巨无霸应用都是亿级用户。不过也不要被这个数据给吓倒了,用户管理虽然数据量巨大,但实现起来并不难,原因是什么呢? 因为用户数据量虽然大,但是不同用户之间没有太强的业务关联,A 用户登录和 B 用户登录基本没有关系。因此虽然数据量巨大,但我们用一个简单的负载均衡架构就能轻松应对。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

互联网架构模板中的用户层技术和业务层技术涉及用户管理、消息推送、存储云和图片云等关键方面。在用户层技术中,处理大规模用户数据的挑战可以通过简单的负载均衡架构轻松解决,而消息推送则需要应对设备管理、连接保活和消息管理等挑战。存储云和图片云则采用“CDN + 小文件存储”技术来处理大量文件数据的上传和访问需求。在业务层技术中,拆分成多个子系统是解决复杂度问题的关键,同时采用“高内聚、低耦合”的原则将子系统合成虚拟业务域,通过网关对外统一呈现。这些技术特点体现了互联网架构模板在用户层和业务层的关键技术挑战和解决方案。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《从 0 开始学架构》
新⼈⾸单¥68
立即购买
登录 后留言

全部留言(39)

  • 最新
  • 精选
  • LouisLimTJ
    当然正确的话是要根据业务和团队来设计虚服务域。但是个人看法,粒度方面要粗一些,本来虚服务域就是来解决系统拆分过细的问题。 至于具体多少个为好,我们可以仿照管理学关于一个一层管理团队的理想大小,其答案不一定,但一般是不要超过10个,我个人比较舒服的数目是3到7个。

    作者回复: 是的,5+-2的选择比较合理

    2018-08-06
    2
    59
  • 课后思考及问题 1:本文核心观点 1-1:面对庞大复杂的东西,用拆字决——化整为零,分而治之。 1-2:面对细微量多的东西,用合字决——分久必合,合二为一。 2:虚拟业务域划分的粒度需要粗一些还是要细一些?你建议虚拟业务域的数量大概是多少,理由是什么? 要粗一些,大概5~7个 理由:虚拟业务域要解决的是划分的系统太细太多的问题,关键是太细导致了太多,这是分而治之现在要合二为一,所以,最好粗一些,咱们的集体领导制最高领导人也就5或7个人,十几亿人民也是管理的好好的。划分的太少,容易集中,复杂化,划分的太多,容易分散,不好管理。

    作者回复: 观点很独特啊😂

    2019-09-04
    2
    13
  • lyonger
    一开始以为互联网架构模版中的技术,会介绍具体的技术知识,结果理论居多。😹

    作者回复: 架构模板目的在于告诉读者一个公司的技术全貌,如果拆开来讲,每个都可以是一个专栏,你可以看看极客时间上其它专栏

    2020-03-22
    2
    9
  • 小神david
    互联网业务千差万别万别,不过如果对比粗细来划分,虚拟域是要粗一些的,因为它出现的目标就是如此,整合更细粒度的微服务。具体数量这个没办法统一来分,结合实际业务情况和团队人员情况而定吧。

    作者回复: 你可以从性能的角度来考虑,加入一个虚拟域处理需要50ms,10个就500ms了,因此我建议不要超过10个。

    2021-03-14
    7
  • 风雨无阻
    虚拟域是不是有点像中台了

    作者回复: 不是中台,中台是不同业务的共性部分,虚拟域还是聚焦在本业务,当然,虚拟域可以依赖中台

    2018-10-11
    6
  • l-m-a
    个人觉得增加了facade层,服务器机器数量提升,另外服务之间的调用并没有减少反而还增加了,facade层的性能直接影响内部服务的能力。

    作者回复: 这也是代价,所以没有完美的解决方案 回到这个方案,当需要引入facade层的时候,服务器数量已经不是问题。另外,服务之间的调用不会减少还会增加,但是整个系统的关系复杂度会降低

    2018-08-06
    6
  • Geek_steven_wang
    数量上应该根据具体业务领域逐层汇总,到达一个团队可接受的数量,一开始建议尽量少5个一下,要考虑后面业务扩展还会加,但最多不建议超过9。 另外问题就是一个域内的服务数量还是多,这个有什么办法吗?不能再汇总出网关了,这样层级太深。

    作者回复: 答案就是域内网关,层级深但是对域外其它系统没什么影响

    2020-01-15
    3
  • 考休
    请问老师,目前大部分系统都是前后端分离的架构,前后台的调用使用jwt做token验证,在这种前提下,还需要考虑单点登录的方案吗,是不是所有的模块只需要采用相同的验证、生成规则就可以了,当然对于微服务架构的话,将鉴权放到网关上完成就可以了,感觉像cas这样的方法像是可以给之前jsp时代用的

    作者回复: 现在微服务都要用单点登录哦

    2019-11-21
    2
    3
  • Geek_b04b12
    有几个知识盲点: 1.facade模式,和工厂模式一个范畴? 2,虚拟业务域中图片中的网关,是啥意思?相对于域名来调用服务?还是别的?在阿里的接口和域名访问,用户能感受到吗?或者作为学习者有验证的端倪吗?

    作者回复: 1. 设计模式里面有详细阐述 2. 这个网关是内部的,可以是protobuf这种协议,也可以是HTTP协议,用户不可见

    2018-08-08
    3
  • 客舟听雨来coding
    这虚拟域感觉有些像领域驱动设计的限界上下文

    作者回复: 大道相通😄

    2019-10-05
    2
收起评论
显示
设置
留言
39
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部