用户层技术

用户管理

单点登录

各个子系统统一登录。单点登录的技术实现手段较多，例如 cookie、JSONP、token 等，目前最成熟的开源单点登录方案当属 CAS，其架构如下

授权登录

允许第三方应用接入，现在最流行的授权登录就是 OAuth 2.0 协议，基本上已经成为了事实上的标准。

用户管理系统面临的主要问题是用户数巨大，用户数据量虽然大，但是不同用户之间没有太强的业务关联，A 用户登录和 B 用户登录基本没有关系。因此虽然数据量巨大，但我们用一个简单的负载均衡架构就能轻松应对。如下：

消息推送

消息推送根据不同的途径，分为短信、邮件、站内信、App 推送。除了 App，不同的途径基本上调用不同的 API 即可完成。例如，短信需要依赖运营商的短信接口，邮件需要依赖邮件服务商的邮件接口，站内信是系统提供的消息通知功能。

App 目前主要分为 iOS 和 Android 推送，iOS 系统比较规范和封闭，基本上只能使用苹果的 APNS；但 Android 较复杂，在国外，用 GCM 和 APNS 差别不大；但是在国内：首先是 GCM 不能用；其次是各个手机厂商都有自己的定制的 Android，消息推送实现也不完全一样。

通常情况下，对于中小公司，如果不涉及敏感数据，Android 系统上推荐使用第三方推送服务，因为毕竟是专业做推送服务的，消息到达率是有一定保证的。

如果涉及敏感数据，需要自己实现消息推送，这时就有一定的技术挑战了。消息推送主要包含 3 个功能：设备管理（唯一标识、注册、注销）、连接管理和消息管理，技术上面临的主要挑战有：

• 海量设备和用户管理，设备数量多，存储管理复杂，同时为了定向推广，需要提取用户的特征，对用户进行分类和打标签；
• 连接保活，一般设备为了省电省流量等原因都会限制应用后台运行，限制应用后台运行后连接通道可能就被中断了，导致消息无法及时的送达；
• 消息管理，实际业务运营中，并不是每个消息都给用户，一般是根据用户特征选择一些消息推送，而用户特征变化大，各种排列组合都有可能，具体的设计方案可以采取规则引擎之类的微内核架构技术；

存储云、图片云

互联网业务场景中，用户会上传各种类型的文件，具有如下几个典型特点：

• 数据量大，用户基数大，用户上传行为频繁；
• 文件体积小，大部分图片是几百 KB 到几 MB，短视频播放时间也是在几分钟内；
• 访问有时效性，大部分文件是刚上传的时候访问最多，随着时间的推移访问量越来越小；

简单来说，存储云和图片云通常的实现都是CDN + 小文件存储，现在有了云之后，除非 BAT 级别，一般不建议自己再重复造轮子了，直接买云服务可能是最快也是最经济的方式。

既然存储云和图片云都是基于“CDN + 小文件存储”的技术，为何不统一一套系统，而将其拆分为两个系统呢？
这是因为图片业务的复杂性导致的，普通的文件基本上提供存储和访问就够了，而图片涉及的业务会更多，包括裁剪、压缩、美化、审核、水印等处理，因此通常情况下图片云会拆分为独立的系统对用户提供服务。

业务层技术

互联网的业务千差万别，不同的业务分解下来有不同的系统，所以业务层没有办法提炼一些公共的系统或者组件。抛开业务上的差异，各个互联网业务发展最终面临的问题都是类似的：业务复杂度越来越高。也就是说，业务层面对的主要技术挑战是复杂度

面对业务层的复杂度挑战，我们有屠龙宝刀，不管什么业务难题，用上屠龙宝刀，问题都能迎刃而解。这把屠龙宝刀就是拆，化整为零、分而治之，将整体复杂性分散到多个子业务或者子系统里面去。具体拆的方式有分层架构、微服务、微内核等。

随着拆拆拆会导致子系统数量越来越多，如果达到几百上千，另外一个复杂度问题又会凸显出来：子系统数量太多，已经没有人能够说清楚业务的调用流程了，出了问题排查也会特别复杂。此时应该怎么处理呢？

此时采取的合的方式是按照高内聚、低耦合的原则，将职责关联比较强的子系统合成一个虚拟业务域，然后通过网关对外统一呈现，类似于设计模式中的 Facade 模式。以电商为样例，采用虚拟业务域后，其结构如下：

--------来源《极客课程》∙ 学习摘要