微服务驱动的应用开发

（1）解除变更周期与其他团队之间的耦合。
（2）相互协作的组件之间的交互是受规范约束的。
（3）持续交付小的、单独的变更，以控制功能受到破坏的风险。

开发某个功能：
（1）需要开发哪些服务。
（2）这些服务之间彼此如何合作。
（3）如何将功能公开出去。

微服务开发生命周期的三大关键迭代阶段——设计、部署和监测

并不是要绝对化地将每个功能都映射为单个微服务。开发者需要判断哪些功能关系紧密——它们要放在一起；将一组功能组合到一起，就形成了一个服务所要提供的能力。

服务协作

（1）同步调用通常要比异步通信更加简单而且更便于排查分析。即便如此，也不要错误地认为它们和本地的进程内的函数调用有同样的特性——跨网络的请求明显要慢很多而且更加不可靠。（2）即便不是所有编程环境，至少大部分都已经支持一种简单、与语言无关而又在开发者中有广泛认知度的传输机制：HTTP。HTTP主要用于同步调用，但是也可以将其用于异步调用。

同步消息的缺点如下。
（1）服务之间耦合更紧，因为服务必须知道协作者的存在。
（2）不能很好地支持广播模型以及发布-订阅模型。这限制了执行并行工作的能力。
（3）在等待响应的时候，代码执行是被阻塞的。在基于线程或者进程的服务模型中，这可能会耗尽资源并触发连锁故障。
（4）过度使用同步消息会导致出现很深的依赖链，而这又会增加调用路径整体的脆弱性。

异步消息更加灵活。开发者可以通过事件通知的方式来扩展系统处理新的需求。因为服务不再需要了解下游的消费者。新服务可以直接消费已有的事件，而不需要对已有的服务进行修改。
这种方式下，应用演化更加平滑，服务间的耦合更低。但是付出的代价是：异步交互更加难以理解，因为整个系统行为不再是那种显式的线性顺序。系统行为变得更加危险——服务间的交互变得不可预测——需要在监控上增加投入来充分地跟踪所发生的情况。

网关

API网关模式是一种很简洁的方式，但是它也有一些缺点，因为作为众多底层服务唯一的组合对外入口，它会变得越来越大，而且可能会越来越笨重。它会诱使开发者将业务逻辑添加到网关中，而非仅仅将其作为一个代理来对待。它试图成为无所不能的可用于所有应用的服务，却又饱受其苦，毕竟不同应用的需求各有不同：移动客户端应用希望返回的数据体积更小、更精简，网页版的内部管理系统所需要的数据却又多得多。在开发高度内聚的API时，开发者要同时平衡这些相互冲突是非常困难的。