【1.综述工程开发】

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

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

一个系统设计什么样子完全由目标决定，可以从原来的单机应用服务器扩展到分布式服务（包含CDN服务器集群，反向代理服务器集群,分布式微服务集群，通用数据代理集群，分布式缓存集群，分布式文件服务器，分布式数据库服务器等）
举个例子一个简单的通用系统逻辑架构如下：
【1.综述工程开发】

高性能

单机高性能

多进程，单进程多线程
每个独立线程处理请求模式：异步、同步(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）可负载均衡位置和方案

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

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等消息队列。排队模块，调度模块，服务模块

故障后

日志记录（服务器上，本地独立系统存储，日志异地保存）
用户补偿

存储高可用

可扩展

常见拆分方案：
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.面向功能：微内核（插件化架构）
【1.综述工程开发】
插件管理，注册，加载时机。插件连接（OSGI，消息模式，依赖注入spring，分布式协议rpc等）。插件通信（核心模块实现）
比如OSGI，Eclipse的Equinox。service层(bundle注册)，lifecycle(管理bundle的安装更新启动停止卸载),bundle
规则引擎架构（开源drools），

效率

研发效率
框架。不同语言和层面的服务关注点不同，讲下thrift和PHP两篇，thrift见:https://segmentfault.com/a/11...
php:https://segmentfault.com/a/11...
问题定位。见https://segmentfault.com/a/11...
环境。容器（见https://segmentfault.com/a/11...）。
线下容器环境，物理机环境，线上预览环境，分级线上环境，仿真环境（见https://segmentfault.com/a/11...）
测试效率
自动化
故障注入
全链路压测。
流量回放。以上见：https://segmentfault.com/a/11...
运维效率

涉及配置下发，资源隔离调度，上线，监控等。见https://segmentfault.com/a/11...
运营
灰度：见https://segmentfault.com/a/11...
可视化运营系统

安全

todo