微服务架构是一种架构模式，提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通（通常是基于HTTP协议的RESTful API）。每个服务都围绕着具体业务进行构建，并且能够被独立的部署到生产环境、类生产环境等。另外，应当尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建。
微服务的设计原则
高内聚低耦合
- 紧密关联的事物应该放在一起，每个服务是针对一个单一职责的业务能力的封装，专注做好一件事情（每次只有一个更改它的理由)。如下图：有四个服务a,b,c,d，但是每个服务职责不单一，a可能在做b的事情，b又在做c的事情，c又同时在做a的事情，通过重新调整，将相关的事物放在一起后，可以减少不必要的服务。
- 轻量级的通信方式
- 同步RESTful（GET/PUT/POST...），基于http，能让服务间的通信变得标准化并且无状态，关于RESTful API的成熟度，可参
Richardson为REST定义的成熟度模型 - 异步（消息队列/发布订阅）
- 避免在服务与服务之间共享数据库
- 单一责任功能具有以下优点：服务组合无缝，更好的扩展，可重用性，可扩展性和可维护性。
高度自治
- 独立部署运行和扩展
- 每个服务能够独立被部署并运行在一个进程内
- 这种运行和部署方式能够赋予系统灵活的代码组织方式和发布节奏，使得快速交付和应对变化成为可能。
- 独立开发和演进
- 技术选型灵活，不受遗留系统技术栈的约束。
- 合适的业务问题可以选择合适的技术栈，可以独立的演进
- 服务与服务之间采取与语言无关的API进行集成
- 独立的团队和自治
- 团队对服务的整个生命周期负责，工作在独立的上下文中， 谁开发，谁维 以业务为中心
- 每个服务代表了特定的业务逻辑
- 有明显的边界上下文
- 围绕业务组织团队
- 能快速的响应业务的变化
- 隔离实现细节，让业务领域可以被重用
- 自主服务具有以下优点：有效的服务编排和协调，更好的扩展，通过良好定义的API进行通信，更快速和可控的部署。
弹性设计
- 设计可容错的系统
- 拥抱失败，为已知的错误而设计
- 依赖的服务挂掉
- 网络连接问题
- 设计具有自我保护能力的系统
- 服务隔离
- 服务降级
- 限制使用资源
- 防止级联错误
日志与监控
当产品环境出错时，需要快速的定位问题，检测可能发生的意外和故障。而日志与监控是快速定位和预防的不二选择，在微服务架构中更是至关重要。
- 高度可观察，需要对正在发生的事情有一个整体的视角。
- 聚合你的日志，聚合你的数据，从而当你遇到问题时，可以深入分析原因。
- 当需要重现令人讨厌的问题，或仅仅查看你的系统在生产环境如何交互时，
关联标识可以帮助你跟踪系统间的调用。
监控主要包括服务可用状态、请求流量、调用链、错误计数，结构化的日志、服务依赖关系可视化等内容，以便发现问题及时修复，实时调整系统负载，必要时进行服务降级，过载保护等等，从而让系统和环境提供高效高质量的服务。
隔离
服务必须设计为单独相互隔离工作。 当你将一个整体单片系统分解成一组服务时，这些服务必须彼此解耦，这样才能更加连贯和自给自足。每个服务应该能够处理其自己的故障，而不会影响或破坏整个应用程序或系统。 隔离和解耦特性使服务能够非常快速地从故障状态中恢复。服务的隔离特性具有以下优点：容易采用连续交付，更好的扩展，有效的监控和可测试性
有界上下文
服务应该有多大或小？ 答案就在于所谓有界上下文设计原则。这是一个关键模式，同时是领域驱动设计（DDD）建模方法。 有界的上下文是关于微服务将提供其服务功能的上下文。根据有关领域模型和识别离散边界，并相应地设计您的微服务，使其更具凝聚力和自主性。 这也意味着跨边界的通信变得更有效率，在一个有界上下文中的服务不需要依赖于另外一个有限上下文中的太多的事情了。
异步通信
在设计离散边界和使用其自己的有界上下文设计服务时，跨边界的服务通信必须是异步的。异步通信模式自然导致服务之间的松耦合，并允许更好的缩放。使用同步通信，会阻止调用并等待响应。 处于阻塞状态的服务不能执行另一个任务，直到接收到响应并释放底层线程为止。它导致网络拥塞，并影响延迟和吞吐量。异步通信还可以带来实现良好定义的集成或通信模式的概念，以实现涉及不同服务的逻辑工作流。
