工程开发

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

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

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

举个例子一个简单的通用系统逻辑架构如下:

高性能

单机高性能

多进程,单进程多线程
每个独立线程处理网络IO模式:异步、同步(actor,reactor,preactor)
网路IO:阻塞、非阻塞(select,poll,epoll)
见:xx  actor,epoll

集群高性能:

1.缓存

本地数据缓存:在存储中讲,略

分布式数据缓存:在存储中讲,略

CDN:见xx

2.扩展服务器,任务分配器(负载均衡)

需要关注分配器选型(硬件F5,软件LVS,nginx)、分配器与服务器之间连接管理,建立,检测,中断后处理、分配算法

负载均衡整体上方案

1)可负载均衡位置和方案

  • DNS 负载均衡
    不需开发,DNS会自动就近访问。缓存更新不及时,扩展性差,分配策略简单无法感觉服务器状态,见:xx
  • 硬件 还具备防火墙,DDos等功能。扩展差。贵。
  • 4层 LVS 见:xx
  • 7层 nginx 见:xx
  • 代码中 配置,服务发现等 见:在微服务中xx

2)负载均衡算法

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

3.任务拆分

简单的系统更容易做到高性能,同时提高扩展性,在扩展性中说

3.通信

公司入网部署 见:xx

长连接 见:xx

网络协议

  • 网络基础 见:xx
  • tcp 见:xx
  • http 见:xx
  • thrift 见:xx

高可用(稳定性建设)

计算高可用

1.部署,可以1主多备或多主多备。

主备(单活):冷备(主从),温被(业务系统一直启动,但不对外提供服务)

集群(多活):对称集群(负载均衡),非对称集群,任务分配器

2.任务分配器

分配算法更复杂,需要有角色状态能力,若多主还需要考虑尽量同一用户落入单机房,当然也可以简单的人工切换。

高可用状态决策

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

任务管理:某台服务器失败,是否要以及如何重新分配到新的服务器执行

3.异地多活(活不是备)

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

异常处理

  • 多通道同步

    数据同步+接口访问(用两种不同的网络连接,一个公网一个内网,优先同步+本地,不行就走接口,多机房需要路由规则记录数据来源,访问来源机器),日志记录(服务器上,本地独立系统存储,日志异地保存),用户补偿

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

  • 降级,降级系统,权限管理,批量操作等
  • 熔断:当a依赖B,B响应慢,A不再请求B。调用层统一采样+统计,设置阈值
  • 限流,基于请求限流,基于资源限流,
  • 排队,kafka等消息队列。排队模块,调度模块,服务模块

存储高可用

存储的东西涉及较多,独立见xx

可扩展

常见拆分方案:

1.面向流程(UI,业务,数据,存储)

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

2.面向服务

  • SOA
  • 微服务
    需要快速交付,轻量级,服务粒度细。small,lightweight,automated
    服务划分太细,服务间关系复杂;数量太多,团队效率下降,平均3人一个;调用链路长,性能下降;调用链路长,问题定位论难;一定要有自动化的测试,部署,监控保障;服务路由,故障隔离,注册和发现等服务治理。
    基于业务逻辑拆分。稳定和变化拆分,稳定服务力度可以粗一些。核心和非核心拆分,只对核心业务做高可用等。基于性能拆分,瓶颈单独部署。

    详见:xx(rpc,服务发现)

3.面向功能:微内核(插件化架构)

插件管理,注册,加载时机。插件连接(OSGI,消息模式,依赖注入spring,分布式协议rpc等)。插件通信(核心模块实现)

比如OSGI,Eclipse的Equinox。service层(bundle注册),lifecycle(管理bundle的安装更新启动停止卸载),bundle

规则引擎架构(开源drools),

成本

  • 研发效率
    框架。不同语言和层面的服务关注点不同,讲下thrift和PHP两篇,见xx
    环境。容器很方便(见xx)。线下容器环境,压测(见xx)物理机环境,线上预览环境,分级线上环境,仿真环境(见xx)
    问题定位。见xx
  • 测试
    自动化
    故障注入 todo
    全链路压测。见xx
    流量回放。见xx
  • 运维

    涉及配置下发,资源隔离调度,上线,监控等。见xx
  • 运营
    灰度:见xx
    运营系统

安全

todo

我来评几句
登录后评论

已发表评论数()

相关站点

热门文章