【1.综述工程开发】

时间 2019-11-05

标签 1.综述工程开发繁體版

原文原文链接

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

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

一个系统设计什么样子彻底由目标决定，能够从原来的单机应用服务器扩展到分布式服务（包含CDN服务器集群，反向代理服务器集群,分布式微服务集群，通用数据代理集群，分布式缓存集群，分布式文件服务器，分布式数据库服务器等）
举个例子一个简单的通用系统逻辑架构以下：
react

高性能

单机高性能

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

集群高性能：

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）负载均衡算法spring

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

高可用（稳定性建设）

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

最小系统/核心数据发现

服务冗余/数据冗余

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.面向功能：微内核（插件化架构）

插件管理，注册，加载时机。插件链接（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