微服务架构 高可用
本文将通过自建架构图 进行讲解
如图采用了分布式、微服务架构，将传统系统进行重构后的效果
微服务架构体系对多个层面进行探索、分析和优化，本文不在详细阐述
微服务、分布式架构根据公司、企业需求定制化构造而来，目的细化模块间的调用，链路更加清晰明了，不同环节高可用方案不同，优化手段也存在差异。
分析思考
如果系统高峰期间可以处理500W/S 请求流量，那么当请求到达1000W/S请求流量时系统是否有安全隐患？需要从哪些方面进行优化？
-
系统可以撑500W/S请求，说明系统500之上都有可能，可以建造一套防生产环境用来进行内部全链路业务压测、外部流量容灾、限流测试，通过此举可以详细发现系统哪个环节处于瓶颈，从来进行具体优化
-
如上图可以通过水平扩展方式从来提升整体处理能力
- F5是瓶颈，外界可以通过多个IP进来，DNS轮询负载到多套F5集群，正常情况F5不会存在瓶颈。
- Nginx负载过高，图上是部署2套Nginx节点，进行估算后可以水平增加Nginx节点
- Varnish缓存基于内存存储，正常存在内存不够情况，当出现后可以增加Varnish节点或增加内存分配
- 业务模块 可以把相同模块分别部署多份，从而提高服务吞吐量
- Rocketmq高性能消息服务器，单台可处理千万级别消息。当消息发送和消费积压严重，Broken负载过高后，可以进行水平扩展（Broken、Provider、Consumer）集群
- Redis高性能缓存服务器，如出现单台负载过大，也可以通过扩展集群模式从而提供高效服务
- Mysql数据库 当出现连接数占满/不够，数据库查询缓慢，可通过扩展集群模式从而提高数据处理效率，Mysql相关优化后续文章会详细讲解
以上是服务器部署图
通过部署图可以发现
- 通过Nginx可指定URL进行轮询调用，意味着系统内部请求可以通过分流方式从而规避风险
- 如特殊消耗性能相关入口可以分发到单独服务器从而进行处理
- 针对服务器相关节点进行监控，如zabbix，提前预知系统处理情况
总结：
微服务架构高可用可以针对不同渠道链路进行探针监控，提前预知其存在风险点，然后通过轮询、切换等方式让其故障转移，不影响业务正常使用运转。其中最为复杂体现在故障期间来回切换所产生的脏数据、重复数据、部分数据丢失等问题。需要进行系统筛选，必要时需要人工干预处理。
作者简介：张程 技术研究
更多文章请关注微信公众号：zachary分解狮 (frankly0423)
