架构学习 - 实战

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

1.1 业务和技术之间的关系

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

2. 技术演进的模式 (复杂性,用户规模)

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

2.1 初创期

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

2.2 发展期

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

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

2.3 竞争期

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

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

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

2.4 成熟期

系统性的针对性优化

3. General

fig1.png

  • 纵向排列
    • 测试平台
    • 运维平台
    • 数据平台
    • 管理平台
  • 横向
    • 业务层
    • 用户层
      • 用户管理
      • 消息推送
      • 存储云
      • 图片云
    • 网络层
      • 负载均衡
      • 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+接口名称

fig2.png

6.2.2 服务总线系统 – Service Bus System

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

fig3.png

fig4.png

6.3 消息队列

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

7. 网络层技术

7.1 负载均衡

  • DNS
    • 地理级别的负载均衡
  • Nginx, LVS, F5
    • 同一个地点内机器级别的负载均衡
  • CDN

    7.2 多机房 + 跨国多机房

    7.3 多中心

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

8. 用户层技术

8.1 用户管理

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

fig5.png

  • 授权登录
    • 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

文章标题:架构学习 - 实战

文章字数:2.4k

本文作者:Leilei Chen

发布时间:2020-02-04, 12:10:07

最后更新:2020-02-04, 12:11:33

原始链接:https://www.llchen60.com/%E6%9E%B6%E6%9E%84%E5%AD%A6%E4%B9%A0-%E5%AE%9E%E6%88%98/

版权声明: "署名-非商用-相同方式共享 4.0" 转载请保留原文链接及作者。

目录
×

喜欢就点赞,疼爱就打赏