2.9 KiB
Executable File
服务框架、注册中心、网关系统
即使你没有用很多微服务架构里的东西，只要有上述三个东西，配合上写一些文档，接口文档，分布式系统架构，其实就出来了，很多中小型公司，一个小型技术团队，后端开发工程师总共就10多个人
关注分布式系统一些生茶实践的问题，应对你们公司的流量，各个服务、网关、注册中心，都是如何部署的，部署几台机器，每台机器的配置是什么，每天整体的流量有多少，高峰期的请求量有多少，你的整体系统是否抗住了
各个服务之间的超时、重试、幂等，是否搞定了
数据库配置和部署
很多同学，他们因为在自己公司里面开发的都是一些单块系统，微服务架构，但是公司没什么流量，他对机器的配置抗多少并发请求，其实没多大的概念，都不是什么技术问题，很多同学出去面试的时候
死扣生产细节问题，每秒3000并发请求，各个服务部署多少机器，机器的配置，数据库的机器和配置，网关的机器和配置，注册中心的机器和配置，什么样的机器配置能抗多大的流量和请求
中小型的系统，拆分为10~20个服务，微服务，庞大的互联网公司，都有几百个、几千个、几万个服务，服务规模，服务注册中心，妥妥的，2~3台机器就足够了，把服务的上线、故障以及发现优化到极致
服务上线，注册表多级缓存同步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负载很高，网络负载很高