工程开发

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

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

一个系统设计什么样子完全由目标决定，可以从原来的单机应用服务器扩展到分布式服务（包含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