互联网架构模板：用户层和业务层技术

第90篇

极客时间《从0开始学架构》课程笔记。

标准技术框架

互联网的标准技术架构

用户层技术

1、用户管理

• 用户管理的第一个目标：单点登录（SSO），又叫统一登录。
• 单点登录的技术实现手段较多，例如 cookie、JSONP、token 等，目前最成熟的开源单点登录方案当属 CAS
• 用户管理的第二个目标：授权登录。现在最流行的授权登录就是 OAuth 2.0 协议，基本上已经成为了事实上的标准
• 业务做大成为了平台后，开放成为了促进业务进一步发展的手段，需要允许第三方应用接入，所以需要授权登录

CAS架构

2. 消息推送

• 消息推送根据不同的途径，分为短信、邮件、站内信、App 推送，短信需要依赖运营商的短信接口，邮件需要依赖邮件服务商的邮件接口，站内信是系统提供的消息通知功能
• App 目前主要分为 iOS 和 Android 推送，iOS 系统比较规范和封闭，基本上只能使用苹果的 APNS
• Android推送比较特殊， 在国外用 GCM 和 APNS ；在国内Android 的消息推送比较杂乱，有实力的大厂都会自己实现一套消息推送机制，例如阿里云移动推送、腾讯信鸽推送、百度云推送；也有第三方公司提供商业推送服务，例如友盟推送、极光推送等
• 消息推送主要包含 3 个功能：设备管理（唯一标识、注册、注销）、连接管理和消息管理，分别对应的技术难点是海量设备和用户管理、连接保活、消息管理

3. 存储云、图片云

• 互联网场景下用户需要上传多种类型的文件数据，包括图片、视频等，特点是数据量大、文件体积小、访问有时效性
• 存储云和图片云通常的实现都是“CDN + 小文件存储”，现在有了“云”之后，直接买云服务可能是最快也是最经济的方式
• 图片涉及的业务包括裁剪、压缩、美化、审核、水印等处理，因此通常情况下图片云会拆分为独立的系统对用户提供服务

业务层技术

• 业务复杂度越来越高。也就是说，业务层面对的主要技术挑战是“复杂度”
• 复杂度越来越高的一个主要原因就是系统越来越庞大，业务越来越多。唯一方法就是“拆”，化整为零、分而治之，将整体复杂性分散到多个子业务或者子系统里
• 随着子系统越来越多，会凸显一个新的复杂度问题：子系统数量太多，已经没有人能够说清楚业务的调用流程了，出了问题排查也会特别复杂
• 解决方法是“合”，但不是合并为一个统一系统，而是按照“高内聚低耦合”原则将职责关联比较强的子系统合成一个虚拟业务域，然后通过网关对外统一呈现

虚拟业务域