Skip to content

Latest commit

 

History

History
51 lines (18 loc) · 2.87 KB

system-framework.md

File metadata and controls

51 lines (18 loc) · 2.87 KB

服务框架、注册中心、网关系统

即使你没有用很多微服务架构里的东西,只要有上述三个东西,配合上写一些文档,接口文档,分布式系统架构,其实就出来了,很多中小型公司,一个小型技术团队,后端开发工程师总共就10多个人

关注分布式系统一些生茶实践的问题,应对你们公司的流量,各个服务、网关、注册中心,都是如何部署的,部署几台机器,每台机器的配置是什么,每天整体的流量有多少,高峰期的请求量有多少,你的整体系统是否抗住了

各个服务之间的超时、重试、幂等,是否搞定了

数据库配置和部署

很多同学,他们因为在自己公司里面开发的都是一些单块系统,微服务架构,但是公司没什么流量,他对机器的配置抗多少并发请求,其实没多大的概念,都不是什么技术问题,很多同学出去面试的时候

死扣生产细节问题,每秒3000并发请求,各个服务部署多少机器,机器的配置,数据库的机器和配置,网关的机器和配置,注册中心的机器和配置,什么样的机器配置能抗多大的流量和请求

中小型的系统,拆分为1020个服务,微服务,庞大的互联网公司,都有几百个、几千个、几万个服务,服务规模,服务注册中心,妥妥的,23台机器就足够了,把服务的上线、故障以及发现优化到极致

服务上线,注册表多级缓存同步1秒,注册表拉取频率降低为1秒 服务心跳,1秒上报1次 故障发现,1秒钟检查一次1心跳,如果发现2秒内服务没上报心跳,认为故障了

服务注册中心都没任何压力,最多就是每秒钟几十次请求而已

服务注册中部署个2台机器,每台机器就是4核8G,高可用冗余,任何一台机器死掉,不会影响系统的运行

服务注册中心这样的一个处理逻辑,4核8G的机器,每秒钟轻松抗几百请求,上千请求也是可以的

通常来说,如果每秒钟的并发在1000以内的话,很少部署的,每个服务部署2台机器,每台机器4核8G,每台机器每秒抗个几百请求,一点问题都没有,别搞出来一个请求过来,查数据库SQL写的太烂了,一条SQL要跑3秒钟

大部分的系统,高峰期每秒几百请求,低峰期每秒几十请求,甚至几个请求

网关系统,4核8G的机器,一台机器抗每秒几百请求,部署3~4台机器,保证可以网关系统每台机器的压力比较小,进一步保证网关系统可靠性

数据库,MySQL,16核32G,物理机最佳,32核64G,最多抗个每秒钟几千请求问题不大,平时抗个每秒钟几十或者几百请求,三四千请求,但是只不过此时会导致MySQL机器的负载很高,CPU使用率很高,磁盘IO负载很高,网络负载很高