架构学习 - 实战

SystemDesign 架构

创建时间:2020-02-04 12:10

字数:2.4k 阅读:

评论:

1. 技术演进的动力 - 企业发展
1. 1.1 业务和技术之间的关系
2. 技术演进的模式（复杂性，用户规模）
3. General
4. 存储层技术
5. 开发层技术
6. 服务层技术
7. 网络层技术
8. 用户层技术
9. 业务层技术
10. 平台技术
11. Some tips
1. 11.1 如何选择开源项目

1. 技术演进的动力 - 企业发展

1.1 业务和技术之间的关系

产品类
- 技术创新推动业务发展
- 用户选择产品的根本驱动力是功能
服务类
- 业务发展推动技术创新
- 用户选择服务的根本驱动力是规模

2. 技术演进的模式（复杂性，用户规模）

业务时期分类
- 初创期
- 发展期
- 竞争期
- 成熟期

2.1 初创期

创新出新的理念，通过用户使用，快速迭代，不断完善。对于业务的要求就是快。

2.2 发展期

大量加入功能，技术方面的核心工作就是快速实现各种需求。

堆功能
优化 vs 重新架构
架构期 - 拆分

2.3 竞争期

更迅速的发展，但是很容易出现重复造轮子，以及系统交互很乱等问题

因此一般都是做平台化以及服务化的操作。

平台化
- 存储平台化
- 数据库平台化
- 缓存平台化

2.4 成熟期

系统性的针对性优化

3. General

纵向排列
- 测试平台
- 运维平台
- 数据平台
- 管理平台
横向
- 业务层
- 用户层
  - 用户管理
  - 消息推送
  - 存储云
  - 图片云
- 网络层
  - 负载均衡
  - CDN
- 服务层
  - 配置中心
  - 服务中心
  - 消息队列
- 开发层
  - 开发框架
  - 服务器
  - 容器
- 存储层
  - SQL
  - NoSQL
  - 小文件
  - 大文件

4. 存储层技术

4.1 SQL

NoSQL - Not only SQL
数据库拆分满足性能要求，但是会带来复杂度问题
- 数据如何拆分
- 数据如何组合
当业务发展到一定阶段之后，会将这部分功能独立成中间件
而后在SQL集群上构建SQL存储平台，以对业务透明的形式提供资源分配、数据备份、迁移、容灾、读写分离、分库分表等一系列服务

4.2 NoSQL

在NoSQL集群的基础上实现统一的存储平台，实现以下的功能：

资源按需动态分配
资源自动化管理
故障自动化管理

4.3 小文件存储

展示性质的数据，比如商品图片，商品描述；特征是数据小，但数量巨大

4.4 大文件存储

业务上的大数据
- youtube的视频
- 电影
海量日志数据
- 访问日志
- 操作日志
- 用户轨迹日志

几个开源方案

Hadoop
HBase
Storm
Hive

5. 开发层技术

5.1 开发框架

整个公司使用同样的框架和技术可以解决组和组之间沟通的问题，大大提升组织和团队的开发效率。

对于框架，应该选择成熟的框架，避免盲目追逐新技术。

java
- SSH
- SpringMVC
- Play
Ruby
- Ruby on Rails
PHP
- ThinkPHP
Python
- Django

5.2 Web服务器

Java
- Tomcat
- JBoss
- Besin
PHP/ Python
- Nginx
Apache

5.3 容器

Docker技术，不跨平台，但是启动快，几乎不占资源

可以基于Docker打造自动化运维

6. 服务层技术

服务层的主要目标就是降低系统间相互关联的复杂度。

6.1 配置中心

集中管理各个系统的配置
各系统管理自己的配置会带来一些问题
- 需要多个系统配合的时候，配置分散，则配置检查和沟通协调都会比较费时间
- 处理线上问题，需要查询多个配置文件，相互比较，很麻烦
- 各系统自己配置，往往用文本方式，没有自动的校验机制，就比较容易出现错误
配置中心，做成通用系统，给所有系统来使用
- 集中配置
- 程序化的规则检查，避免常见错误，可以用正则表达式来检查
- 备份了系统的配置，便于快速搭建系统和恢复业务

6.2 服务中心

服务中心是用来解决跨系统依赖的配置和调度问题的。

6.2.1 服务名字系统 – Service Name System

将Service的名称解析为host+port+接口名称

6.2.2 服务总线系统 – Service Bus System

有总线系统完成调用，服务请求方不需要直接和服务提供方进行交互了。

6.3 消息队列

很多业务处理需要采用异步的方式，消息队列就是为了实现这种跨系统异步通知的中间件系统。

7. 网络层技术

7.1 负载均衡

DNS
- 地理级别的负载均衡
Nginx, LVS, F5
- 同一个地点内机器级别的负载均衡
CDN
7.2 多机房 + 跨国多机房
7.3 多中心

每个中心都可以对外提供服务，且业务可以自动在多中心之间切换。

8. 用户层技术

8.1 用户管理

单点登录 (SSO) - 统一登录
- cookie
- Json
- token
- CAS

授权登录
- OAuth 2.0

8.2 消息推送

根据途径
- 短信
- 邮件
- 站内信
- App推送
消息推送的功能
- 设备管理
  - 唯一标识
  - 注册
  - 注销
- 连接管理
- 消息管理

技术上的挑战：

海量设备和用户管理
- 需要将用户和设备关联起来
- 提取用户特征对用户进行分类或者打标签
连接保活
- 想推送消息必须有连接通道
- 但是手机等终端都会限制后台应用的运行
- 应用找厂商拉白名单，hhhh
消息管理
- 根据用户的特征，选择一些用户进行消息推送
- 这部分的逻辑的设计必须十分灵活
  8.3 存储云，图片云
小文件存储

9. 业务层技术

主要是随着发展业务层变得越来越大了，需要做的最主要的就是拆分了，将整体复杂性分散到多个子业务或者子系统当中。

当子系统太多的时候，再做高内聚，低耦合的操作，即将职责关联比较强的子系统合成一个虚拟业务域，然后通过网关对外统一呈现。

10. 平台技术

10.1 运维平台

配置
- 主要负责资源的管理
  - 机器管理
  - IP地址管理
  - 虚拟机管理
部署
- 主要负责将系统发布到线上
  - 包管理
  - 灰度发布管理
  - 回滚
监控
- 主要负责收集系统上线运行之后的相关数据并进行监控，以便及时发现问题
应急
- 主要负责系统出故障以后的处理
  - 停止程序
  - 下线故障机器
  - 切换IP

10.2 测试平台

单元测试
集成测试
接口测试
性能测试

重点就是自动化测试，使测试用例能够重复执行，无须人工参与，以提高测试效率。

10.2.1 用例管理

测试自动化的主要手段就是通过脚本或者代码来进行测试，为了重复执行此类代码，测试平台需要将用例进行管理，管理的维度有业务、系统、测试类型、用例代码。例如网购业务的订单系统的接口测试用例。

10.2.2 资源管理

具体的运行环境的配置，包括

硬件
- 服务器
- 手机
- 平板
软件
- 操作系统
- 数据库
- Java虚拟机
业务系统

10.2.3 任务管理

将测试用例分配到具体的资源上来执行，跟踪任务的执行情况。任务管理是测试平台设计的核心，其将测试平台的各个部分串联起来从而完成自动化测试

10.2.4 数据管理

记录各种相关的数据

执行时间
执行结果
用例执行期间的CPU，内存占用情况

10.3 数据平台

数据管理
- 数据采集
  - 日志
  - 用户行为
  - 业务数据
- 数据存储
  - 将从业务系统采集的数据存储到数据平台，用于后续数据分析
- 数据访问
  - 负责对外提供各种协议用于读写数据
- 数据安全
数据分析
- 数据统计
- 数据挖掘
- 机器学习
- 深度学习
数据应用

10.4 管理平台

管理平台的核心职责就是权限管理，要做身份认证以及权限控制。

身份认证
- 确定当前的操作人员身份，防止非法人员进入系统
权限控制
- 根据身份确定权限

11. Some tips

11.1 如何选择开源项目

不要重复造轮子
但要找到合适的轮子

11.1.1 选择方法

聚焦于是否满足业务，而不是聚焦于开源项目本身是否足够优秀
聚焦于该项目是否足够成熟
- 版本号
- 使用的公司数量
- 社区活跃程度
聚焦于运维能力
- 开源项目日志是否齐全
- 是否有命令行，管理控制台等维护工具
- 是否有故障检测和恢复的能力，例如告警，切换等

11.1.2 如何深入了解一个开源项目

通读开源项目的设计文档，白皮书，了解其设计原理
核对每个配置项的作用和影响，识别出关键配置项
进行多种场景的性能测试
进行压力测试，观察CPU、内存、磁盘I/O等关键指标
进行故障测试

11.1.3 如何基于开源项目做二次开发

不改动原系统，因为还要要能够合并，与原来的能够兼容就再好不过了
开发辅助系统
- 监控
- 报警
- 负载均衡
- 管理

转载请注明来源，欢迎对文章中的引用来源进行考证，欢迎指出任何有错误或不够清晰的表达。可以在下面评论区评论，也可以邮件至 stone2paul@gmail.com