从0开始学架构
李运华
资深技术专家
立即订阅
38983 人已学习
课程目录
已完结 59 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 照着做,你也能成为架构师!
免费
基础架构 (13讲)
01 | 架构到底是指什么?
02 | 架构设计的历史背景
03 | 架构设计的目的
04 | 复杂度来源:高性能
05 | 复杂度来源:高可用
06 | 复杂度来源:可扩展性
07 | 复杂度来源:低成本、安全、规模
08 | 架构设计三原则
09 | 架构设计原则案例
10 | 架构设计流程:识别复杂度
11 | 架构设计流程:设计备选方案
12 | 架构设计流程:评估和选择备选方案
13 | 架构设计流程:详细方案设计
高性能架构模式 (8讲)
14 | 高性能数据库集群:读写分离
15 | 高性能数据库集群:分库分表
16 | 高性能NoSQL
17 | 高性能缓存架构
18 | 单服务器高性能模式:PPC与TPC
19 | 单服务器高性能模式:Reactor与Proactor
20 | 高性能负载均衡:分类及架构
21 | 高性能负载均衡:算法
高可用架构模式 (10讲)
22 | 想成为架构师,你必须知道CAP理论
23 | 想成为架构师,你必须掌握的CAP细节
24 | FMEA方法,排除架构可用性隐患的利器
25 | 高可用存储架构:双机架构
26 | 高可用存储架构:集群和分区
27 | 如何设计计算高可用架构?
28 | 业务高可用的保障:异地多活架构
29 | 异地多活设计4大技巧
30 | 异地多活设计4步走
31 | 如何应对接口级的故障?
可扩展架构模式 (6讲)
32 | 可扩展架构的基本思想和模式
33 | 传统的可扩展架构模式:分层架构和SOA
34 | 深入理解微服务架构:银弹 or 焦油坑?
35 | 微服务架构最佳实践 - 方法篇
36 | 微服务架构最佳实践 - 基础设施篇
37 | 微内核架构详解
架构实战 (13讲)
38 | 架构师应该如何判断技术演进的方向?
39 | 互联网技术演进的模式
40 | 互联网架构模板:“存储层”技术
41 | 互联网架构模板:“开发层”和“服务层”技术
42 | 互联网架构模板:“网络层”技术
43 | 互联网架构模板:“用户层”和“业务层”技术
44 | 互联网架构模板:“平台”技术
45 | 架构重构内功心法第一式:有的放矢
46 | 架构重构内功心法第二式:合纵连横
47 | 架构重构内功心法第三式:运筹帷幄
48 | 再谈开源项目:如何选择、使用以及二次开发?
49 | 谈谈App架构的演进
50 | 架构实战:架构设计文档模板
特别放送 (7讲)
架构专栏特别放送 | “华仔,放学别走!”第1期
架构专栏特别放送 | “华仔,放学别走!” 第2期
如何高效地学习开源项目 | “华仔,放学别走!” 第3期
架构师成长之路 | “华仔,放学别走!” 第4期
架构师必读书单 | “华仔,放学别走!” 第5期
新书首发 | 《从零开始学架构》
致「从0开始学架构」专栏订阅用户
结束语 (1讲)
结束语 | 坚持,成就你的技术梦想
从0开始学架构
登录|注册

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

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

用户层技术

1. 用户管理
互联网业务的一个典型特征就是通过互联网将众多分散的用户连接起来,因此用户管理是互联网业务必不可少的一部分。
稍微大一点的互联网业务,肯定会涉及多个子系统,这些子系统不可能每个都管理这么庞大的用户,由此引申出用户管理的第一个目标:单点登录(SSO),又叫统一登录。单点登录的技术实现手段较多,例如 cookie、JSONP、token 等,目前最成熟的开源单点登录方案当属 CAS,其架构如下(https://apereo.github.io/cas/4.2.x/planning/Architecture.html
除此之外,当业务做大成为了平台后,开放成为了促进业务进一步发展的手段,需要允许第三方应用接入,由此引申出用户管理的第二个目标:授权登录。现在最流行的授权登录就是 OAuth 2.0 协议,基本上已经成为了事实上的标准,如果要做开放平台,则最好用这个协议,私有协议漏洞多,第三方接入也麻烦。
用户管理系统面临的主要问题是用户数巨大,一般至少千万级,QQ、微信、支付宝这种巨无霸应用都是亿级用户。不过也不要被这个数据给吓倒了,用户管理虽然数据量巨大,但实现起来并不难,原因是什么呢? 因为用户数据量虽然大,但是不同用户之间没有太强的业务关联,A 用户登录和 B 用户登录基本没有关系。因此虽然数据量巨大,但我们用一个简单的负载均衡架构就能轻松应对。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《从0开始学架构》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(28)

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

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

    2018-08-06
    23
  • 小美
    老师好 方便什么时候介绍下单点登录sso吗
    2018-08-30
    6
  • feifei
    这个肯定要粗一些,高内聚么,这样肯定功能类似的都被合并为一个了!我觉得控制在个位数吧!我觉得这是相对的一个平衡吧

    作者回复: 是的,粗一些比较好,5+-2原则比较合适

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

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

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

    作者回复: 大道相通😄

    2019-10-05
    1
  • 张玮(大圣)
    既然上升到虚拟域了,粒度粗一些会好很多,细的话容易淹没在业务中,理不清域之间边界了。

    从以前经历的一些项目得出的结论,10 个全是比较多了,再多的话就需要加入子域来说明了。

    最后,一起陪伴走过这么多专栏课时,运华兄辛苦!

    作者回复: 虚拟域粒度确实要粗一些。
    感谢你的鼓励,再辛苦也值得😄

    2018-08-08
    1
  • 张玮(大圣)
    既然上升到虚拟域了,粒度粗一些会好很多,细的话容易淹没在业务中,理不清域之间边界了。

    从以前经历的一些项目得出的结论,10 个全是比较多了,再多的话就需要加入子域来说明了。

    最后,一起陪伴走过这么多专栏课时,运华兄辛苦!
    2018-08-08
    1
  • wuhulala
    明白了 我们的子工程是单独提供服务的 子系统应该是老师说的那个虚拟域
    2018-08-08
    1
  • wuhulala
    我们现在比如说有一个a子系统里面有两个子工程b和c b和c单独提供服务 那么这样b和 c算是两个微服务 a算是虚拟业务域 如果是这样的话 我认为这样划分逻辑清晰 也无需多做什么工作 有何不可呢。期待答疑

    作者回复: 子工程不算微服务,微服务能独立部署和运行

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

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

    2018-08-06
    1
  • 探索无止境
    不知不觉专栏就到尾声了,感谢老师的梳理,把我的整个知识体系理顺了,是否可以提供一些相关技术延伸的优质文章链接,老师是否有开新专栏的打算?

    作者回复: 1. 文章链接太多了,没法一一列出,掌握了架构思想后,可以分辨哪些是好的文章
    2. 没有,写专栏太累😀

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

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

    2019-11-21
  • Geek_88604f
    根据两个披萨原则划分团队,每个团队负责一个虚拟域;域内根据三个火枪手的原则划分微服务
    2019-10-12
  • Sam.张朝
    原来最初接触微服务,只知道要拆分,不能拆分过细。
    现在是要按照业务域拆分合并。

    作者回复: 很多公司都经历过拆然后合并

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

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

    2019-09-04
  • 亚林
    前面提到的三个火枪手原则吧
    2019-04-29
  • wikili
    在同一个虚拟业务域下合并的两个业务子系统自我调用怎么实现的?比如A子系统需要调用B子系统

    作者回复: 微服务调用,需要服务注册发现

    2019-01-24
  • 风雨无阻
    虚拟域是不是有点像中台了

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

    2018-10-11
  • 奋斗心
    这一个星期学到很多。感谢,纠正我不少理解
    DDD专栏名字叫什么,没找到

    作者回复: 是CSDN有DDD专栏,我记错了😀

    2018-10-01
  • 小美
    老师好 方便介绍下单点登录吗

    作者回复: 你需要什么程度的介绍呢?专栏已经简单介绍了😄

    2018-08-30
收起评论
28
返回
顶部