（1）微服务非常适合于有多维复杂性的系统，比如产品的供应范围、全球部署和监管压力。
    （2）在设计微服务时，了解产品业务领域是至关重要的。
    （3）服务交互可以是编配型的，也可以是编排型的。后者会增加系统复杂度，但是能够降低系统中服务之间的耦合度。
    （4）API网关是一种常见的模式，它将微服务架构的复杂性进行了封装和抽象，所以前端或者外部消费者不需要考虑这部分复杂度。
    （5）如果开发者充分信任自己的服务能够处理生产环境上的流量压力，就可以说这个服务是生产就绪的。
    （6）如果开发者可以可靠地部署和监控某个服务，就可以对这个服务更有信心。
    （7）服务监控应该包括日志聚合以及服务层次的健康检查。
    （8）微服务会因硬件、通信以及依赖项等原因而出现故障，并不是只有代码中的缺陷才会导致故障发生。
    （9）收集业务指标、日志以及服务间的链路跟踪记录对于了解微服务应用当前和过去的运行表现是至关重要的。
    （10）随着微服务以及支持团队的数量的不断增加，技术分歧以及孤立会日渐成为技术团队的挑战。
    （11）避免技术分歧和孤立需要在不同团队间采用相似的标准和最佳实践，不管采用何种技术基础。

    （1）单独来讲，微服务的内部和单体应用是相似的。
    （2）微服务应用就像一个街区：它最终的样子不是指定好的，而是由一系列的准则和高层的概要模型来指导实现的。
    （3）指导微服务架构的准则会反映出组织的目标并对团队的实践产生影响。
    （4）架构规划应该促进良性发展，而不是强行指定整个应用的方案。
    （5）微服务应用是由四层组成的：平台层、服务层、边界层和客户端层。
    （6）平台层提供了一系列的工具和基础设施来支持开发面向生产的服务。
    （7）在微服务应用中，同步通信通常是第一选择，并且它非常适合命令型的交互，但是也存在缺点——会增加耦合性和不稳定性。
    （8）异步通信更加灵活，能够适应快速的系统演化，付出的代价是复杂度增加。
    （9）常见的异步通信模式包括队列和发布-订阅。
    （10）边界层就是微服务应用的一个门面，对于外部消费者来说，这是非常适合的。
    （11）常见的边界层模式有API网关和消费者驱动的网关（如GraphQL）。
    （12）客户端应用，比如网站和移动端应用，通过边界层与移动后端进行交互。
    （13）客户端有越来越臃肿庞大的风险，但是现在也开始出现一些将微服务原则应用于前端应用的技术。