🚌一个人可以走的很快，一群人可以走的很远🇨🇳 🎉点赞➕评论➕收藏 ➕关注== 养成习惯（一键四连）📝 🎉欢迎关注💗一起学习👍一起讨论⭐️一起进步📝 🙏作者水平有限，欢迎各位大佬指点，相互学习进步！😆
微服务概念提出者的个人网站：https://martinfowler.com/microservices/
简而言之，微服务架构风格是一种将单个应用程序开发为一组小服务的方法，每个小服务都在自己的进程中运行，并与轻量级机制（通常是 HTTP 资源 API）进行通信。这些服务是围绕业务能力构建的，并且可以 通过完全自动化的部署机制独立部署。有一个集中管理的最低限度的这些服务，可以用不同的编程语言和使用不同的数据存储技术。 ——詹姆斯·刘易斯和马丁·福勒 (2014)
维基上对其定义为：一种软件开发技术- 面向服务的体系结构（SOA）架构样式的一种变体，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通（通常是基于HTTP的RESTful API）。每个服务都围绕着具体业务进行构建，并且能够独立地部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据上下文，选择合适的语言、工具对其进行构建。
微服务（或微服务架构）是一种云原生架构方法，其中单个应用程序由许多松散耦合且可独立部署的较小组件或服务组成。这些服务通常 ● 有自己的堆栈，包括数据库和数据模型； ● 通过REST API，事件流和消息代理的组合相互通信； ● 它们是按业务能力组织的，分隔服务的线通常称为有界上下文。
尽管有关微服务的许多讨论都围绕体系结构定义和特征展开，但它们的价值可以通过相当简单的业务和组织收益更普遍地理解： ● 可以更轻松地更新代码 ● 团队可以为不同的组件使用不同的堆栈。 ● 组件可以彼此独立地进行缩放，从而减少了因必须缩放整个应用程序而产生的浪费和成本，因为单个功能可能面临过多的负载。
微服务提供了好处 ● 强大的模块边界：微服务加强了模块化结构，这对于大型团队尤为重要。 ● 独立部署：简单的服务更容易部署，并且由于它们是自治的，因此出现问题时不太可能导致系统故障。 ● 技术多样性：借助微服务，您可以混合多种语言、开发框架和数据存储技术。
但要付出代价 ● 分布式：分布式系统更难编程，因为远程调用很慢并且总是有失败的风险。 ● 最终一致性：对于分布式系统来说，保持强一致性是极其困难的，这意味着每个人都必须管理最终一致性。 ● 运营复杂性：您需要一个成熟的运营团队来管理大量定期重新部署的服务。
总结：不建议小团队使用，小团队最好就是用HTTP直接调用。
有大量的公司开发人员，微服务只用一次，且几乎都是自己调用自己，其实已经失去了微服务的意义，微服务一定是在基于功能重复多次调用的情况下，才有意义，如果业务只是被一方调用，不推荐使用微服务。
