https://gudaoxuri.gitbook.io/microservices-architecture/ (微服务架构设计)
1.基本流程
需求分析-->story设计-->story开发-->story测试-->专业测试-->版本发布
2.现网相关
现网变更流程:
发起请求(同时给出变更方案) --> 审批 --> 会签 --> 执行
变更时间:
晚上(凌晨)为佳
生产上, 出现问题时:
先回滚, 然后定位问题
3.系统设计
https://mp.weixin.qq.com/s/MMAnfzaq0WtyN6R3zSv0CA (系统演变过程)
图片.png
图片.png
3.1高可用设计
#1.设计上高可用
各层级, 组件, 系统或模块间通讯点支持高可用, 任一节点挂掉, 请求都可以转至其他节点或者备用节点上,
若无法自动切换, 需要有监控告警机制, 以便于手动恢复
#2.部署高可用
同一cluster不同节点应该部署在不同的物理机上, 可以采用下述3AZ设计:
双活(AZ1, AZ2) + 容灾(AZ3)
3.2可扩展设计
#复制节点:
可通过增加同一cluster节点来扩容
#垂直切分:
不同功能分到不同的部署实例上
#水平切分:
同一功能的不同数据分到不同的实例上
3.3容量规划
一般, 每个月或者每个季度都需要进行一次的容量评估, 评估参考指标为:
TPS, RT, PAYLOAD, 吞吐量, DB或REDIS或KAFKA数据量,
并发量, CDN命中率, redis的Key命中率等
基于上述因素进行建模, 进行压测, 从而设计合理的容量范围
3.4分布式常考虑因素
流控(nginx, waf, ribbon等)
降级
熔断
超时(幂等性考虑)
解耦(推荐使用一部调用, 要避免多于5个的长链路调用, 避免循环调用)
容错设计(同步转为异步, 降级, 读历史缓存等)
3.5充分测试
多环境测试:
开发进行严格自测(写单元测试, 转测前show case)
测试进行功能, 性能, 安全测试(其他分类包括黑盒或白盒测试等)
部署一套准现网环境进行仿真测试(也可导入现网真实数据进行测试)
部署到生产后, 也要进行功能, 性能, 安全测试
3.6严谨变更
在业务调用的低谷时进行变更(如凌晨)
支持一键回滚
支持灰度发布
版本要尽量向下兼容
3.7监控告警
对于请求量, 响应时, 异常状态码, 超时调用, 服务器相关指标, 中间件状况进行采集
设计合理的监控告警机制:
如告警分级, 告警抑制等
3.8去中心化
避免中心节点故障导致全局风险
3.9其他
对于直接使用开源软件的情况, 要注意防坑
4.性能调优
基本概念
代码优化 ---> 架构优化 ---> 链路优化
#TPS
每秒钟处理完的事务次数，一般 TPS 是对整个系统来讲的。
一个应用系统 1s 能完成多少事务处理，
一个事务在分布式处理中，可能会对应多个请求，
对于衡量单个接口服务的处理能力，用 QPS 比较多。
#QPS
每秒钟处理完请求的次数；注意这里是处理完。
具体是指发出请求到服务器处理完成功返回结果。
可以理解在 Server 中有个 Counter，每处理一个请求加 1，1 秒后 Counter = QPS。
#RT
响应时间，处理一次请求所需要的平均处理时间
#并发量
系统能同时处理的请求数
先分析! 先分析! 先分析! 使用分析器来找到真正的瓶颈
#1.使用vmstat, top命令, htop命令(需安装htop插件)进行OS及CPU的诊断
#OS 诊断
OS 的诊断主要关注的是 CPU、Memory、I/O 三个方面。
#CPU 诊断
对于 CPU 主要关注平均负载（Load Average），CPU 使用率，上下文切换次数（Context Switch）。
#2.使用jstack, JProfiler, jstat, jmap, MAT等进行GC, 内存, 堆栈分析等
4.1架构层次
1) 设计合理的业务逻辑
2) 选择合适的编程模型, 尽可能采用异步编程模型, 如:
spring5.0
springboot2.0
vertx
netty
4.2数据库表层次
设计合理的表结构, 建立合适的索引及存储引擎
利用sql执行计划, 查看问题sql等
具体详见:
参见 ---> https://www.jianshu.com/p/f65efc4cd860
4.3java代码设计层次
1) 日志层面:
选择合适的日志打印级别
尽量采用日志的异步打印
2) 对象的序列化及反序列化:
尽量采用阿里巴巴的fastjson组件
3) 非必要, 不加synchronized同步锁
4) 合适场景下, 使用CAS系列
5) 尽量避免随意使用静态变量
6) 尽量避免过多过常地创建Java对象(String s = "he"; --> 不要new String("he");
7) 尽量使用final修饰符
8) 尽量处理好包装类型和基本类型两者的使用场所
9) 禁用finalize方法
10) 尽量使用基本数据类型代替对象
11) 尽量减少对变量的重复计算
for(int i = 0, size = list.size(); i < size; i ++){}
12) 尽量在finally块中释放资源(java7有更优雅的关资源方式)
13) 尽量使用移位来代替'a/b'的操作
14) 尽量确定StringBuffer, HashMap, ArrayList的容量
15) 尽量避免使用split
16) 尽量使用System.arraycopy ()代替通过来循环复制数组
17) 尽量缓存经常使用的对象(采用本地缓存组件, Guava, Caffine, ehcache等)
18) 慎用异常
19) 不要在循环中使用Try/Catch语句，应把Try/Catch放在循环最外层
20) 在使用同步机制时，应尽量使用方法同步代替代码块同步。
21) 不用new关键字创建对象的实例(对象实现Cloneable接口，调用它的clone()方法)
22) 不要将数组声明为：public static final; 不要对数组使用toString()方法
23) 尽量重用对象
24) 适时地关闭流, 连接, 连接池, socket等各种资源类
25) 尽量采用懒加载的策略，即在需要的时候才创建
26) 不要创建一些不使用的对象，不要导入一些不使用的类
27) 程序运行过程中少用反射
28) 使用数据库连接池和线程池
29) 顺序插入和随机访问比较多的场景使用ArrayList，元素删除和中间插入比较多的场景使用LinkedList
30) 把基本数据类型转为字符串效率: 基本数据类型.toString() > String.valueOf(数据) > 数据+”最慢
31) 对于ThreadLocal使用前或者使用后一定要先remove
32) 推荐使用JDK7中新引入的Objects工具类来进行对象的equals比较
33) 循环体内不要使用”+”进行字符串拼接，而直接使用StringBuilder不断append
34) 静态类、单例类、工厂类将它们的构造函数置为private
4.4缓存及其中间件使用
#接口调优:
分布式缓存: 参看阿里巴巴的redis使用规范
本地缓存: 如echche, guava(CacheBuilder等), caffine
#静态资源调优:
CDN加速
------nginx的缓存
4.5web容器的配置(如nginx, tomcat等)
#nginx
配置为长连接, 线程数的设计, 日志问题, 多台 Nginx 负载，前端加 LVS等
服务器集群+负载均衡
#tomcat
4.6基础性能的调优
指的是硬件层级或者操作系统层级的升级优化，
比如网络调优，操作系统版本升级，硬件设备优化等。
比如 F5 的使用和 SDD 硬盘的引入，
包括新版本 Linux 在 NIO 方面的升级，都可以极大的促进应用的性能提升；
4.7JVM调优
参见 ---> https://www.jianshu.com/p/8c0adcdbafa5
5.性能指标
5.1 概念
#TPS
Transactions Per Second 每秒处理的事务数(如果是数据库，就相当于写入、修改)
TPS 的过程包括：客户端请求服务端、服务端内部处理、服务端返回客户端。
例如，访问一个 Index 页面会请求服务器 3 次，包括一次 html，一次 css，一次 js，
那么访问这一个页面就会产生一个“TPS”，产生三个“QPS”。
#QPS
Queries Per Second 每秒处理的查询数（如果是数据库，就相当于读取）
#IOPS
每秒磁盘进行的I/O操作次数
#Throughput（吞吐量）
按照常规理解网络吞吐量表示在单位时间内通过网卡数据量之和，其中即包括本机网卡发送出去的数据量也包括本机网卡接收到的数据量。 一个100Mb(位)的双工网卡，最大发送数据的速度是12.5M字节/s ， 最大接收数据的速度是12.5M字节/s， 可以 同时 收发 数据。
#并发用户数
是同时执行操作的用户(线程数)。
#响应时间
从请求发出到收到响应花费的时间 。
#PV
PV是page view的简写, 页面浏览量。
PV是指页面的访问次数，每打开或刷新一次页面，就算做一个pv。
#UV 访问数（Unique Visitor）
指独立访客访问数，统计1天内访问某站点的用户数(以 cookie 为依据)，一台电脑终端为一个访客。
#GMV
是 Gross Merchandise Volume 的简称。
只要是订单，不管消费者是否付款、卖家是否发货、是否退货，都可放进 GMV 。
5.2 应用
5.2.1 性能监控指标, TP50/TP99
TP50、TP90和TP99等指标常用于系统性能监控场景，指高于50%、90%、99%等百分线的情况。
>> TP50的意思是保证50%请求都能被响应的最小耗时。
>> TP90的意思是保证90%请求都能被响应的最小耗时。
>> TP99的意思是保证99%请求都能被响应的最小耗时。
5.2.2 如何计算服务器能够承受多大的pv？
一个能承受500万PV/每天的网站咋搞？服务器每秒要处理多少个请求才能应对？如果计算呢？
#计算模型：
每台服务器每秒处理请求的数量=((80%总PV量)/(24小时60分60秒40%)) / 服务器数量 。
其中关键的参数是80%、40%。
表示一天中有80%的请求发生在一天的40%的时间内。
24小时的40%是9.6小时，有80%的请求发生一天的9.6个小时当中
（很适合互联网的应用，白天请求多，晚上请求少）。
#简单计算的结果：
((80%500万)/(24小时60分60秒40%))/1 = 115.7个请求/秒
((80%100万)/(24小时60分60秒40%))/1 = 23.1个请求/秒
#初步结论：
现在我们在做压力测试时，就有了标准，如果你的服务器一秒能处理115.7个请求，就可以承受500万PV/每天。
如果你的服务器一秒能处理23.1个请求，就可以承受100万PV/每天。
#留足余量：
以上请求数量是均匀的分布在白天的9.6个小时中，但实际情况并不会这么均匀的分布，会有高峰有低谷。
为了应对高峰时段，应该留一些余地，最少也要x2倍，x3倍也不为过。
115.7个请求/秒 *2倍=231.4个请求/秒
115.7个请求/秒 *3倍=347.1个请求/秒
23.1个请求/秒 *2倍=46.2个请求/秒
23.1个请求/秒 3倍=69.3个请求/秒
#最终结论：
如果你的服务器一秒能处理231.4--347.1个请求/秒，就可以应对平均500万PV/每天。
如果你的服务器一秒能处理46.2--69.3个请求，就可以应对平均100万PV/每天。
#说明：
这里说明每秒N个请求，就是QPS。因为我关心的是应用程序处理业务的能力。
#实际经验：
1、根据实际经验，采用两台常规配置的机架式服务器，配置是很常见的配置，
例如一个4核CPU+4G内存+服务器SAS硬盘。
2、硬盘的性能很重要，由其是数据库服务器。
一般的服务器都配1.5万转的SAS硬盘，高级一点的可以配SSD固态硬盘，性能会更好。
最最最最重要的指标是“随机读写性能”而不是“顺序读写性能”。
3、一台服务器跑Tomcat运行j2ee程序,一台服务器跑MySql数据库,程序写的中等水平(这个真的不好量化)，
是论坛类型的应用(总有回帖,不太容易做缓存,也无法静态化)。
4、以上软硬件情况下，是可以承受100万PV/每天的。(已留有余量应对突然的访问高峰)
#注意机房的网络带宽：
有人说以上条件我都满足了，但实际性能还是达不到目标。
这时请注意你对外的网络的带宽，在国内服务器便宜但带宽很贵，
很可能你在机房是与大家共享一条100M的光纤，实际每个人可分到2M左右带宽。
再好一点5M,再好一点双线机房10M独享，这已经很贵了（北京价格）。
#一天总流量：
每个页面20k字节100万个页面/1024=19531M字节=19G字节，
19531M/9.6小时=2034M/小时=578K字节/s 如果请求是均匀分布的，
需要5M（640K字节）带宽（5Mb=640KB 注意大小写，b是位，B是字节，差了8倍），
但所有请求不可能是均匀分布的，当有高峰时5M带宽一定不够，X2倍就是10M带宽。
10M带宽基本可以满足要求。
以上是假设每个页面20k字节，基本不包含图片，
要是包含图片就更大了，10M带宽也不能满足要求了。你自已计算吧。
参考
https://www.jianshu.com/p/51d82de75d3d
http://www.cnblogs.com/redcreen/archive/2011/05/04/2037057.html
https://mp.weixin.qq.com/s/n_z_2d7mr6t1DVTeQ-kwQw
