工程开发

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

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

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