一、设计原则之围绕业务构建
正所谓，“不围绕业务构建的架构就是耍流氓”
微服务应当聚焦于某一特定的业务功能，并确保完成它
其实这给需求管理也带来了挑战，需求需要切分将更加精细，以满足系统业务的不断变化
在传统的方式中，一般是产品人员进行需求调研，然后经过整理后提交给开发团队，这种方式在微服务的环境下需要重新定义，即产品核实需求后，需要提交给开发团队之前进行评审，评审需要开发团队的人员参与，确认无误后在提交给开发团队
从技术上说，微服务不应该局限于某个技术栈或后端存储，可以非常灵活，以便于解决业务问题
这一点在非微服务系统设计时，可能导致我们做一些妥协
而微服务可以让你用你认为最合适的方式解决问题
这和上面的统一框架并不冲突，统一是指构建团队的过程中，尽量保持统一的架构，从而降低交互和沟通所带来的额外成本
系统可以根据业务切分为不同的子系统，子系统又可以根据重要程序切分为核心和非核心子系统
切分的目的就是当出现问题时，保证核心业务模块正常运行，不影响业务的正常操作
同时解决各个模块子系统间的耦合、维护和扩展性
方便单独部署，确保当一个系统出现问题时，不会出现连锁反应而导致整个系统瘫痪
各个系统间合理地使用消息队列，解决系统或模块间的异步通信，实现高可用、高性能的通信系统
二、设计原则之并发流量控制
大流量一般的衡量指标就是系统的 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 做得不是很好，没有充分利用处理器能力
在微服务架构下，如果涉及不同类型的业务，需要根据资源的使用情况选用合适的处理资源
参考资料：《微服务架构实战》—— 张锋
一 叶 知 秋，奥 妙 玄 心
)
