【SpringCloud】设计原则之围绕业务构建与并发流量控制

一、设计原则之围绕业务构建

正所谓，“不围绕业务构建的架构就是耍流氓”

微服务应当聚焦于某一特定的业务功能，并确保完成它 

其实这给需求管理也带来了挑战，需求需要切分将更加精细，以满足系统业务的不断变化 

在传统的方式中，一般是产品人员进行需求调研，然后经过整理后提交给开发团队，这种方式在微服务的环境下需要重新定义，即产品核实需求后，需要提交给开发团队之前进行评审，评审需要开发团队的人员参与，确认无误后在提交给开发团队 

从技术上说，微服务不应该局限于某个技术栈或后端存储，可以非常灵活，以便于解决业务问题 

这一点在非微服务系统设计时，可能导致我们做一些妥协 

而微服务可以让你用你认为最合适的方式解决问题 

这和上面的统一框架并不冲突，统一是指构建团队的过程中，尽量保持统一的架构，从而降低交互和沟通所带来的额外成本 

系统可以根据业务切分为不同的子系统，子系统又可以根据重要程序切分为核心和非核心子系统 

切分的目的就是当出现问题时，保证核心业务模块正常运行，不影响业务的正常操作 

同时解决各个模块子系统间的耦合、维护和扩展性 

方便单独部署，确保当一个系统出现问题时，不会出现连锁反应而导致整个系统瘫痪 

各个系统间合理地使用消息队列，解决系统或模块间的异步通信，实现高可用、高性能的通信系统

 

二、设计原则之并发流量控制 

大流量一般的衡量指标就是系统的 TPS（每秒事务量）和 QPS（每秒请求量） 

其实这个没有一个绝对的标准，一般都是根据机器的配置情况而定的，如果当前配置不能应对请求量，那么就视为大流量了 

 

一般的应对方案包括：

• 缓存

预先准备好数据，减少对数据库的请求 

• 降级 

如果不是核心链路，那么就把这个服务降级，保证主干通畅 

• 限流 

在一定时间内把请求限制在一定范围内，保证系统不被冲垮，同时尽可能提升系统的吞吐量 

限流的方式有几种，最简单的就是使用计数器，在一段时间内，进行计数，与阈值进行比较，到了时间临界点，将计数器清零 

 

应对并发，很重要的一点就是区分 CPU 密集型和 I / O 密集型 

• CPU 密集型（CPU-bound） 

CPU 密集型也叫计算密集型，指的是系统的硬盘、内存性能相对 CPU 要好很多 

此时，系统运作大部分的状况是 CPU Loading 100%，CPU 要读 / 写 I / O（硬盘 / 内存），I / O 在很短的时间就可以完成，而 CPU 还有许多运算要处理，CPU Loading 很高

CPU bound 的程序一般而言 CPU 占用率很高 

这可能是因为任务本身不太需要访问 I / O 设备，也可能是因为程序是多线程实现，因此屏蔽掉了等待 I / O 的时间 

• I / O 密集型（I / O bound）

I / O 密集型指的是系统的 CPU 性能相对硬盘、内存要好很多

此时，系统运作大部分的状况是 CPU 在等 I / O（硬盘 / 内存）的读 / 写操作，此时 CPU Loading 并不高 

I / O bound 的程序一般在达到性能极限时，CPU 占用率仍然较低 

这可能是因为任务本身需要大量 I / O 操作，而 pipeline 做得不是很好，没有充分利用处理器能力 

在微服务架构下，如果涉及不同类型的业务，需要根据资源的使用情况选用合适的处理资源 

 

参考资料：《微服务架构实战》—— 张锋 

 

一  叶  知  秋，奥  妙  玄  心