43 | 互联网架构模板：“用户层”和“业务层”技术
李运华
该思维导图由 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
《从 0 开始学架构》，新⼈⾸单¥68
立即购买
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(39)
- 最新
- 精选
LouisLimTJ当然正确的话是要根据业务和团队来设计虚服务域。但是个人看法，粒度方面要粗一些，本来虚服务域就是来解决系统拆分过细的问题。 至于具体多少个为好，我们可以仿照管理学关于一个一层管理团队的理想大小，其答案不一定，但一般是不要超过10个，我个人比较舒服的数目是3到7个。作者回复: 是的，5+-2的选择比较合理
2018-08-06259
钱课后思考及问题 1：本文核心观点 1-1：面对庞大复杂的东西，用拆字决——化整为零，分而治之。 1-2：面对细微量多的东西，用合字决——分久必合，合二为一。 2：虚拟业务域划分的粒度需要粗一些还是要细一些？你建议虚拟业务域的数量大概是多少，理由是什么？ 要粗一些，大概5～7个 理由：虚拟业务域要解决的是划分的系统太细太多的问题，关键是太细导致了太多，这是分而治之现在要合二为一，所以，最好粗一些，咱们的集体领导制最高领导人也就5或7个人，十几亿人民也是管理的好好的。划分的太少，容易集中，复杂化，划分的太多，容易分散，不好管理。作者回复: 观点很独特啊😂
2019-09-04213
lyonger一开始以为互联网架构模版中的技术，会介绍具体的技术知识，结果理论居多。😹作者回复: 架构模板目的在于告诉读者一个公司的技术全貌，如果拆开来讲，每个都可以是一个专栏，你可以看看极客时间上其它专栏
2020-03-2229- 小神david互联网业务千差万别万别，不过如果对比粗细来划分，虚拟域是要粗一些的，因为它出现的目标就是如此，整合更细粒度的微服务。具体数量这个没办法统一来分，结合实际业务情况和团队人员情况而定吧。
作者回复: 你可以从性能的角度来考虑，加入一个虚拟域处理需要50ms，10个就500ms了，因此我建议不要超过10个。
2021-03-147 
风雨无阻虚拟域是不是有点像中台了作者回复: 不是中台，中台是不同业务的共性部分，虚拟域还是聚焦在本业务，当然，虚拟域可以依赖中台
2018-10-116
l-m-a个人觉得增加了facade层，服务器机器数量提升，另外服务之间的调用并没有减少反而还增加了，facade层的性能直接影响内部服务的能力。作者回复: 这也是代价，所以没有完美的解决方案 回到这个方案，当需要引入facade层的时候，服务器数量已经不是问题。另外，服务之间的调用不会减少还会增加，但是整个系统的关系复杂度会降低
2018-08-066- Geek_steven_wang数量上应该根据具体业务领域逐层汇总，到达一个团队可接受的数量，一开始建议尽量少5个一下，要考虑后面业务扩展还会加，但最多不建议超过9。 另外问题就是一个域内的服务数量还是多，这个有什么办法吗？不能再汇总出网关了，这样层级太深。
作者回复: 答案就是域内网关，层级深但是对域外其它系统没什么影响
2020-01-153 
考休请问老师，目前大部分系统都是前后端分离的架构，前后台的调用使用jwt做token验证，在这种前提下，还需要考虑单点登录的方案吗，是不是所有的模块只需要采用相同的验证、生成规则就可以了，当然对于微服务架构的话，将鉴权放到网关上完成就可以了，感觉像cas这样的方法像是可以给之前jsp时代用的作者回复: 现在微服务都要用单点登录哦
2019-11-2123
Geek_b04b12有几个知识盲点： 1.facade模式，和工厂模式一个范畴？ 2，虚拟业务域中图片中的网关，是啥意思？相对于域名来调用服务？还是别的？在阿里的接口和域名访问，用户能感受到吗？或者作为学习者有验证的端倪吗？作者回复: 1. 设计模式里面有详细阐述 2. 这个网关是内部的，可以是protobuf这种协议，也可以是HTTP协议，用户不可见
2018-08-083
客舟听雨来coding这虚拟域感觉有些像领域驱动设计的限界上下文作者回复: 大道相通😄
2019-10-052
收起评论
