1. 微服务的原则
- 围绕业务概念建模，经验表明，围绕业务的限界上下文定义的接口，比围绕技术概念定义的接口更稳定。
- 拥抱自动化文化，微服务包含太多复杂性的东西，比如我们不得不管理大量的服务。所以最好的方式是在前期花费一定的时间构建支持微服务的工具；还有自动化的测试，部署脚本等等，能够帮我们做大多数耗时间的事情。
- 隐藏内部实现细节，为了使一个服务独立于其他服务，最大化独自演化的能力。限界上下文建模在这方面可以提供帮助。服务还应该隐藏它们的数据库，以避免陷入数据耦合。在可能的情况下选择支持通用技术的API，这能让你自由选择使用不同的技术栈。
- 可独立部署，通过采用单服务单主机模式，可以减少部署引发的副作用。考虑使用蓝/绿部署或金丝雀部署技术。
- 隔离失败，我们得考虑下游服务可能发生失败的情况，否则系统会遭受灾难性的故障。所以请记住“反脆弱的方式”，比如正确设置超时，了解何时及如何使用舱壁和断路器。
2. 什么时候不应该使用微服务
- 第一个建议是，你越不了解一个领域，为服务找到合适的上下文就越难。前面说过，服务的界限划分错误，可能会导致不得不频繁的更改服务间的协作，这种成本很高。所以在划分服务之前，第一件事情是花一些时间了解系统是做什么的，然后尝试识别出清晰的模块边界。如果是一个全新的业务领域，请首先考虑构建单块系统，稳定以后再拆分。
3. 最后的赠言
微服务架构给我们带来更多的选择，也需要我们做更多的决策。所以，我们避免不了在某些决策上犯错，所以请尽量所以决策影响范围，这里的思想是拥抱演进式架构。
每个组织构建的微服务都是独一无二的，不要去追寻所谓的标准，最好把他们当做参考。我们的系统需要逐步改变和演进，以适应我们的业务，在任何时候我们的业务都能够正常且具有一定效率的进行，就可以说明我们的系统是稳定而有效的。