上一期，我从计算机网络层的角度谈了应对“高性能”和“高可用”的整体架构设计。今天，我将从“用户层”和“业务层”的角度谈谈常见的应用场景和关键技术。
用户层技术
1.用户管理
互联网业务的一个典型特征就是通过互联网将众多分散的用户连接起来，因此用户管理是互联网业务必不可少的一部分。
稍微大一点的互联网业务，肯定会涉及多个子系统，这些子系统不可能每个都管理这么庞大的用户，由此引申出用户管理的第一个目标：单点登录（SSO），又叫统一登录。单点登录的技术实现手段较多，例如cookie、JSONP、token等，目前最成熟的开源单点登录方案当属CAS，其架构如下（https://apereo.github.io/cas/4.2.x/planning/Architecture.html ）：
除此之外，当业务做大成为了平台后，开放成为了促进业务进一步发展的手段，需要允许第三方应用接入，由此引申出用户管理的第二个目标：授权登录。现在最流行的授权登录就是OAuth 2.0协议，基本上已经成为了事实上的标准，如果要做开放平台，则最好用这个协议，私有协议漏洞多，第三方接入也麻烦。
用户管理系统面临的主要问题是用户数巨大，一般至少千万级，QQ、微信、支付宝这种巨无霸应用都是亿级用户。不过也不要被这个数据给吓倒了，用户管理虽然数据量巨大，但实现起来并不难，原因是什么呢？ 因为用户数据量虽然大，但是不同用户之间没有太强的业务关联，A用户登录和B用户登录基本没有关系。因此虽然数据量巨大，但我们用一个简单的负载均衡架构就能轻松应对。
用户管理的基本架构如下：
2.消息推送
消息推送根据不同的途径，分为短信、邮件、站内信、App推送。除了App，不同的途径基本上调用不同的API即可完成，技术上没有什么难度。例如，短信需要依赖运营商的短信接口，邮件需要依赖邮件服务商的邮件接口，站内信是系统提供的消息通知功能。
App目前主要分为iOS和Android推送，iOS系统比较规范和封闭，基本上只能使用苹果的APNS；但Android就不一样了，在国外，用GCM和APNS差别不大；但是在国内，情况就复杂多了：首先是GCM不能用；其次是各个手机厂商都有自己的定制的Android，消息推送实现也不完全一样。因此Android的消息推送就五花八门了，大部分有实力的大厂，都会自己实现一套消息推送机制，例如阿里云移动推送、腾讯信鸽推送、百度云推送；也有第三方公司提供商业推送服务，例如友盟推送、极光推送等。
通常情况下，对于中小公司，如果不涉及敏感数据，Android系统上推荐使用第三方推送服务，因为毕竟是专业做推送服务的，消息到达率是有一定保证的。
如果涉及敏感数据，需要自己实现消息推送，这时就有一定的技术挑战了。消息推送主要包含3个功能：设备管理（唯一标识、注册、注销）、连接管理和消息管理，技术上面临的主要挑战有：
-
海量设备和用户管理
消息推送的设备数量众多，存储和管理这些设备是比较复杂的；同时，为了针对不同用户进行不同的业务推广，还需要收集用户的一些信息，简单来说就是将用户和设备关联起来，需要提取用户特征对用户进行分类或者打标签等。 -
连接保活
要想推送消息必须有连接通道，但是应用又不可能一直在前台运行，大部分设备为了省电省流量等原因都会限制应用后台运行，限制应用后台运行后连接通道可能就被中断了，导致消息无法及时的送达。连接保活是整个消息推送设计中细节和黑科技最多的地方，例如应用互相拉起、找手机厂商开白名单等。 -
消息管理
实际业务运营过程中，并不是每个消息都需要发送给每个用户，而是可能根据用户的特征，选择一些用户进行消息推送。由于用户特征变化很大，各种排列组合都有可能，将消息推送给哪些用户这部分的逻辑要设计得非常灵活，才能支撑花样繁多的业务需求，具体的设计方案可以采取规则引擎之类的微内核架构技术。
3.存储云、图片云
互联网业务场景中，用户会上传多种类型的文件数据，例如微信用户发朋友圈时上传图片，微博用户发微博时上传图片、视频，优酷用户上传视频，淘宝卖家上传商品图片等，这些文件具备几个典型特点：
-
数据量大：用户基数大，用户上传行为频繁，例如2016年的时候微信朋友圈每天上传图片就达到了10亿张（http://mi.techweb.com.cn/tmt/2016-05-25/2338330.shtml）。
-
文件体积小：大部分图片是几百KB到几MB，短视频播放时间也是在几分钟内。
-
访问有时效性：大部分文件是刚上传的时候访问最多，随着时间的推移访问量越来越小。
为了满足用户的文件上传和存储需求，需要对用户提供文件存储和访问功能，这里就需要用到前面我在专栏第40期介绍“存储层”技术时提到的“小文件存储”技术。简单来说，存储云和图片云通常的实现都是“CDN + 小文件存储”，现在有了“云”之后，除非BAT级别，一般不建议自己再重复造轮子了，直接买云服务可能是最快也是最经济的方式。
既然存储云和图片云都是基于“CDN + 小文件存储”的技术，为何不统一一套系统，而将其拆分为两个系统呢？这是因为“图片”业务的复杂性导致的，普通的文件基本上提供存储和访问就够了，而图片涉及的业务会更多，包括裁剪、压缩、美化、审核、水印等处理，因此通常情况下图片云会拆分为独立的系统对用户提供服务。
业务层技术
互联网的业务千差万别，不同的业务分解下来有不同的系统，所以业务层没有办法提炼一些公共的系统或者组件。抛开业务上的差异，各个互联网业务发展最终面临的问题都是类似的：业务复杂度越来越高。也就是说，业务层面对的主要技术挑战是“复杂度”。
复杂度越来越高的一个主要原因就是系统越来越庞大，业务越来越多。幸运的是，面对业务层的技术挑战，我们有一把“屠龙宝刀”，不管什么业务难题，用上“屠龙宝刀”问题都能迎刃而解。这把“屠龙宝刀”就是“拆”，化整为零、分而治之，将整体复杂性分散到多个子业务或者子系统里面去。具体拆的方式你可以查看专栏前面可扩展架构模式部分的分层架构、微服务、微内核等。
我以一个简单的电商系统为例，如下图所示：
我这个模拟的电商系统经历了3个发展阶段：
-
第一阶段：所有功能都在1个系统里面。
-
第二阶段：将商品和订单拆分到2个子系统里面。
-
第三阶段：商品子系统和订单子系统分别拆分成了更小的6个子系统。
上面只是个样例，实际上随着业务的发展，子系统会越来越多，据说淘宝内部大大小小的已经有成百上千的子系统了。
随着子系统数量越来越多，如果达到几百上千，另外一个复杂度问题又会凸显出来：子系统数量太多，已经没有人能够说清楚业务的调用流程了，出了问题排查也会特别复杂。此时应该怎么处理呢，总不可能又将子系统合成大系统吧？最终答案还是“合”，正所谓“合久必分、分久必合”，但合的方式不一样，此时采取的“合”的方式是按照“高内聚、低耦合”的原则，将职责关联比较强的子系统合成一个虚拟业务域，然后通过网关对外统一呈现，类似于设计模式中的Facade模式。同样以电商为样例，采用虚拟业务域后，其架构如下：
小结
今天我为你讲了互联网架构模板中的用户层技术和业务层技术，希望对你有所帮助。
这就是今天的全部内容，留一道思考题给你吧，虚拟业务域划分的粒度需要粗一些还是要细一些？你建议虚拟业务域的数量大概是多少，理由是什么？
欢迎你把答案写到留言区，和我一起讨论。相信经过深度思考的回答，也会让你对知识的理解更加深刻。（编辑乱入：精彩的留言有机会获得丰厚福利哦！）
精选留言
2018-08-06 04:44:58
至于具体多少个为好，我们可以仿照管理学关于一个一层管理团队的理想大小，其答案不一定，但一般是不要超过10个，我个人比较舒服的数目是3到7个。
2018-08-30 21:48:53
2019-09-04 07:35:12
1：本文核心观点
1-1：面对庞大复杂的东西，用拆字决——化整为零，分而治之。
1-2：面对细微量多的东西，用合字决——分久必合，合二为一。
2：虚拟业务域划分的粒度需要粗一些还是要细一些？你建议虚拟业务域的数量大概是多少，理由是什么？
要粗一些，大概5～7个
理由：虚拟业务域要解决的是划分的系统太细太多的问题，关键是太细导致了太多，这是分而治之现在要合二为一，所以，最好粗一些，咱们的集体领导制最高领导人也就5或7个人，十几亿人民也是管理的好好的。划分的太少，容易集中，复杂化，划分的太多，容易分散，不好管理。
2020-03-22 22:12:38
2021-03-14 21:35:09
2018-10-11 09:40:20
2018-08-06 12:53:58
2020-01-15 06:47:12
另外问题就是一个域内的服务数量还是多，这个有什么办法吗？不能再汇总出网关了，这样层级太深。
2019-11-21 20:00:27
2018-08-08 23:46:11
1.facade模式，和工厂模式一个范畴？
2，虚拟业务域中图片中的网关，是啥意思？相对于域名来调用服务？还是别的？在阿里的接口和域名访问，用户能感受到吗？或者作为学习者有验证的端倪吗？
2019-10-05 10:17:40
2019-09-29 15:36:10
现在是要按照业务域拆分合并。
2019-01-24 09:10:52
2018-08-26 07:56:08
2018-08-10 17:28:49
2018-08-08 18:42:33
从以前经历的一些项目得出的结论，10 个全是比较多了，再多的话就需要加入子域来说明了。
最后，一起陪伴走过这么多专栏课时，运华兄辛苦！
2018-08-07 07:48:53
2018-08-04 10:55:18
2022-04-26 09:49:08
2020-03-14 11:56:46
用户管理
单点登录sso，又叫统一登录。
单点登录的技术实现包括cookie，jsonp，token等，比较成熟的开源单点登录方案当属cas。
在业务变大，成长为平台后，又引出了用户管理的第二个目标：授权登录。现在流行的就是oauth2.0协议。
消息推送
消息推送根据不同途径，分为短信，邮件，站内信，app推送。除了app推送以外，不同的途径基本上调用不同的app即可完成。
重点的app推送包括ios推送，以及android推送，ios一般用apns推送就好了，而android就不一样了，在国外google cloud message是可以用的，但是在国内是没法用的。所以就衍生了各种版本，主要有大厂自己实现的消息推送机制（阿里云移动推送，腾讯信鸽推送，百度云推送），以及专业的第三方公司提供的推送服务（友盟推送，极光推送）。
消息推送主要包括三个功能：设备管理（唯一标识，注册，注销），连接管理和消息管理器
如果要自己处理的话，那么要注意三点挑战。
海量设备和用户管理
为方便业务推广，还需要收集用户信息，将用户跟设备关联，提取用户特征对用户进行分类和打标签。
连接保活
一般设备为了节省电（流）量，都会限制应用后台运行，限制应用后台运行连接通道可能被中断，导致消息不可达。方法有很多，比如互相拉起，找手机厂商开白名单。
消息管理
实际业务中，需要根据用户的特征选择一些用户进行消息推送，由于用户特征变化大，需要将推送给哪部分用户的逻辑设计非常灵活，才能满足需求。
存储云，图片云
互联网场景下，用户会上传多种类型的文件数据，这样文件的特点：
1）数据量大，用户基数大
2）文件体积小，几百kb到几mb，
3）访问有时效性，大部分文件是刚上传时访问最多，随着时间的推移访问量越来越小。
存储云/图片云都是基于cdn+小文件存储的技术，没有合并的原因在于图片业务复杂还包括裁剪，压缩，美化，审核，水印等处理。
业务层技术
随着业务复杂度越来越高，一般的方法就是拆，化整为零，分而治之，将整体复杂性分散到多个子业务/子系统里面去。
当然随着子系统数量越来越多，还可以采用合的做法，比如，按照高内聚，低耦合的原则。将职责关联比较强的子系统合成一个虚拟业务域，通过网关对外统一呈现，类似于facade设计模式。
虚拟业务域划分应该越细越好，因为要按照高内聚低耦合的原则，虚拟业务域数量一般3-5个？具体原因不太清楚，平常业务中没有涉及到。。。。