CmdSmith的博客

当然面向用户的接口请求一般到不了这个量级，QPS递增大多是由于读放大造成的压力，单也属于高并发架构考虑的范畴。具体多少QPS跟业务强相关，只读接口读缓存，将压力给到缓存单机3000+没问题，写请求1000+也正常，也复杂些可能也就几百+QPS。假定总并发请求数量为10000，每个请求的处理时间为t秒，服务器一次性可以处理的请求数量为n个，那么处理完所有的请求需要用时为T。所以QPS和业务场景和设计相关性很大，比如可以通过浏览器本地缓存，用缓存做热点数据查询，写事务MQ异步处理等方式提升QPS。

微服务拆分没有一个绝对正确的方案，服务拆分的粒度完全要根据业务场景来规划，而随着业务的发展，原先的架构方案也需要做调整。

微服务路由模式负责处理希望消费微服务的客户端应用程序，使客户端应用程序发现服务的位置并路由到服务。在基于云的应用程序中，可能会运行成百上千个微服务实例。需要抽象这些服务的物理IP地址，并为服务调用提供单个入口点，以便为所有服务调用持续强制安全和内容策略。服务发现和服务路由并不彼此依赖。服务发现和路由是所有大规模微服务应用的关键部分。服务发现从客户端抽象出服务的物理位置。可以添加新的微服务实...

1.10 使用 Spring Cloud 构建微服务从零实现所有的微服务模式是一项巨大的工作。Spring 团队将大量经过实战检验的开源项目整合到一个称为Spring Cloud 的 Spring 子项目中。Spring Cloud 将 Pivotal、HashiCorp 和 Netflix 等开源公司的工作封装在一起。Spring Cloud简化了将这些项目设置和配置到Spring 应用程序...