【1.综述工程开发】

梦想家

更不知道起什么名字。我想归纳下一个通用系统(不考虑功能差异)的设计目标和对应实现方法,如果本人公司涉及到的会详细讲一下,也供架构设计搭建参考。本篇是个整体,其中涉及内容会分篇

目标:
    ——高性能
    ——高可用
    ——可扩展
    ——成本=》效率(运维,研发效率,测试效率,物理成本与其他分不开暂不考虑)
    ——安全

一个系统设计什么样子完全由目标决定,可以从原来的单机应用服务器扩展到分布式服务(包含CDN服务器集群,反向代理服务器集群,分布式微服务集群,通用数据代理集群,分布式缓存集群,分布式文件服务器,分布式数据库服务器等)
举个例子一个简单的通用系统逻辑架构如下:
clipboard.png

高性能

单机高性能

多进程,单进程多线程
每个独立线程处理请求模式:异步、同步(actor,reactor,preactor)
每个独立线程处理网络IO模式:阻塞、非阻塞、非阻塞多路复用(select,poll,epoll)
底层IO:同步、异步(NIO)
数据共享:加锁/通信传递actor
见:https://segmentfault.com/a/11...

集群高性能:

1.缓存
本地数据缓存:在存储中讲,略
分布式数据缓存:在存储中讲,略
CDN:见https://segmentfault.com/a/11...
2.扩展服务器,任务分配器(负载均衡)
需要关注分配器选型(硬件F5,软件LVS,nginx)、分配器与服务器之间连接管理,建立,检测,中断后处理、分配算法
负载均衡整体上方案
1)可负载均衡位置和方案

2)负载均衡算法

  • HASH
    源地址hash
    目标地址hash
    session id hash,用户id hash 适用于临时保存的场景
  • 轮询
    平分
    加权轮询
    负载最低优先(比如CPU负载,连接数,IO使用,网卡等,LVS可以以连接数来判断,其他因为收集负载耗资源,应用场景没有轮询多)
    性能最优类(响应时间,收集,采样,统计周期)

3.任务拆分
简单的系统更容易做到高性能,同时提高扩展性,在扩展性中说
3.通信
公司入网部署 见:https://segmentfault.com/a/11...
长连接 见:https://segmentfault.com/a/11...
网络协议 以下见:https://segmentfault.com/a/11...

  • 网络基础
  • tcp
  • http
  • thrift

高可用(稳定性建设)

多数稳定性建设是故障前建设。故障中减低影响,故障后补偿

最小系统/核心数据发现

服务冗余/数据冗余

1.部署,可以1主多备或多主多备。
主备(单活):冷备(主从),温被(业务系统一直启动,但不对外提供服务)
集群(多活):对称集群(负载均衡),非对称集群,任务分配器
2.任务分配器
分配算法更复杂,需要有角色状态能力,若多主还需要考虑尽量同一用户落入单机房,当然也可以简单的人工切换。
高可用状态决策

1.一个决策者,多个上报者
2.2个机器协商,注意脑裂检测
3.民主决策,=》脑裂 当集群连接中断,解决办法投票节点数必须超过系统总节点一半,当可用少于一半时系统不可用

任务管理:某台服务器失败,是否要以及如何重新分配到新的服务器执行
3.异地多活(活不是备)

  • 异地
    同城异区,解决机房级别故障,可以通过搭建高速网络,和同一个机房一样设计(0.5ms/0.07ms)
    跨城异地,网络抖动时,延时会很高,数据不一致,支付宝等金融系统对余额这类数据不会做跨城异地,应对极端灾难场景
    跨国多活:不同地区不能相互访问,或几秒以上延时无感知的只读服务
  • 原则
    保证核心业务的异地多活,保证核心业务数据最终一致性
    减少异地多活机房的距离,搭建高速网络
    只保证绝大部分用户的异地多活。挂公告,事后补偿等
  • 挑选核心业务:访问量大的,核心功能,产生大量收入业务
  • 数据
    带存储异地多活比较难,见:https://segmentfault.com/a/11...。全局唯一ID,该生成ID方案也要异地多活,idc生成个方案:https://segmentfault.com/a/11...
    分类:数据量,唯一性,实时性,可丢失性,可恢复性。根据不同数据设计不同同步方案,避免少量数据异常导致整体业务不可用
    采取多种手段同步数据,除了存储系统等自带的同步功能,消息队列方式,二次读取,回源读取,重新生成数据等

链路

  • 多通道同步
    数据同步+接口访问(用两种不同的网络连接,一个公网一个内网,优先同步+本地,不行就走接口,多机房需要路由规则记录数据来源,访问来源机器)

接口级故障,保证核心业务和绝大部分用户(bug等内存耗尽等,第三方系统大量请求或响应慢,攻击,促销等)

  • 降级,降级系统,降级点识别(批量操作等)
  • 熔断:当a依赖B,B响应慢,A不再请求B。调用层统一采样+统计,设置阈值,见微服务
  • 限流,基于请求限流,基于资源限流,nginx讲了限流的详细做法
    固定数量1)1s内限制死数量24位时间戳+8位数量,取当前s如果一样+后8位,如果不一样初始时间戳+0
    2)流入速率和流出速率 当前剩余令牌=上次剩余令牌+1-rate*时差{本该消耗的令牌}>0/超出限制
    3)自适应的 固定数量=maxqps{最近采样极大qps}*(2minlat{0负载延时}-avglat{当前延时})。(本来延时-超出部分)*qps。0负载延时最近小值的平均,逐步减少maxqps获取。
  • 排队,kafka等消息队列。排队模块,调度模块,服务模块

故障后

  • 日志记录(服务器上,本地独立系统存储,日志异地保存)
  • 用户补偿

存储高可用

存储的东西涉及较多,独立见https://segmentfault.com/a/11...

可扩展

常见拆分方案:
1.面向流程(UI,业务,数据,存储)
分层架构 保证各层之间的差异足够清晰,边界明显,本质就是隔离关注点,要保证层与层之间的依赖是稳定的,B/S,C/S MVC(逻辑都在M,C只是转发)/MVP(逻辑在P,M是数据),逻辑分层(自顶向下依赖比如端=》框架=》库=》内核),建议层层不能被跨越,两两依赖,否则时间久会乱比如sdk和common。缺点是冗余和每次都要经过所有层
2.面向服务

  • SOA 服务+系统总线(比较重,负责服务定义、服务路由、消息转换、消息传递,)+服务松耦合
  • 微服务
    需要快速交付,轻量级,服务粒度细。small,lightweight,automated相比如SOA的系统总线,微服务推荐使用统一的协议和格式,例如,RESTful协议、RPC协议,服务做的比较多总线轻量。更小。
    服务划分太细,服务间关系复杂;数量太多,团队效率下降,平均3人一个;调用链路长,性能下降;调用链路长,问题定位论难;一定要有自动化的测试,部署,监控保障;服务路由,故障隔离,注册和发现等服务治理。
    基于业务逻辑拆分。稳定和变化拆分,稳定服务力度可以粗一些。核心和非核心拆分,只对核心业务做高可用等。基于性能拆分,瓶颈单独部署。
    详见:https://segmentfault.com/a/11...

3.面向功能:微内核(插件化架构)
clipboard.png
插件管理,注册,加载时机。插件连接(OSGI,消息模式,依赖注入spring,分布式协议rpc等)。插件通信(核心模块实现)
比如OSGI,Eclipse的Equinox。service层(bundle注册),lifecycle(管理bundle的安装更新启动停止卸载),bundle
规则引擎架构(开源drools),

效率

安全

todo

阅读 2k
107 声望
70 粉丝
0 条评论
107 声望
70 粉丝
宣传栏