微服务架构介绍
微服务架构是一种将服务器应用程序构建为一组小型服务的方法
微服务架构是一种将服务器应用程序构建为一组小型服务的方法。这意味着微服务架构主要面向后端，尽管该方法也被用于前端。每个服务都在自己的进程中运行，并使用HTTP / HTTPS，WebSockets或AMQP等协议与其他进程通信。每个微服务在特定的上下文边界内实现特定的端到端域或业务功能，并且每个微服务必须自主开发并且可以独立部署。最后，每个微服务都应拥有其相关的域数据模型和域逻辑（主权和分散数据管理），并且可以基于不同的数据存储技术（SQL，NoSQL）和不同的编程语言。
微服务的大小应该是多少？在开发微服务时，大小不应该是重点。相反，重要的一点应该是创建松耦合的服务，以便您可以自主开发，部署和扩展每个服务。当然，在识别和设计微服务时，只要与其他微服务之间没有太多直接依赖关系，就应尝试使其尽可能小。比微服务的大小更重要的是它必须具有的内部凝聚力以及与其他服务的独立性。
为什么是微服务架构？简而言之，它提供了长期的灵活性。微服务使您可以基于许多可独立部署的服务创建应用程序，从而在复杂，大型和高度可扩展的系统中实现更好的可维护性，每个服务均具有细化和自治的生命周期。
此外，微服务可以独立扩展。您不必拥有必须作为一个单元进行扩展的单个整体应用程序，而可以扩展特定的微服务。这样，您可以仅扩展需要更多处理能力或网络带宽来支持需求的功能区域，而不必扩展应用程序中不需要扩展的其他区域。这意味着可以节省成本，因为您需要更少的硬件。
如图所示，在传统的整体方法中，应用程序通过将整个应用程序克隆到多个服务器/ VM中进行扩展。在微服务方法中，功能被隔离在较小的服务中，因此每个服务都可以独立扩展。微服务方法允许对每个微服务进行敏捷更改和快速迭代，因为您可以更改复杂，大型和可伸缩应用程序的特定，较小区域。
架构基于微服务的细粒度应用程序可以实现持续集成和持续交付实践。它还加快了向应用程序中交付新功能的速度。应用程序的细粒度组合还使您可以隔离地运行和测试微服务，并在保持它们之间明确的合同的同时自主地发展它们。只要不更改接口或协定，就可以更改任何微服务的内部实现或添加新功能，而不会破坏其他微服务。
以下是使基于微服务的系统成功投入生产的重要方面：
对服务和基础结构的监视和运行状况检查。
服务的可扩展基础架构（即云和协调器）。
多个级别的安全性设计和实现：身份验证，授权，秘密管理，安全通信等。
快速交付应用程序，通常由不同的团队专注于不同的微服务。
DevOps和CI / CD实践和基础架构。
好处
敏捷。由于微服务是独立部署的，因此更易于管理错误修复和功能发布。您可以在不重新部署整个应用程序的情况下更新服务，并在出现问题时回滚更新。在许多传统应用程序中，如果在应用程序的某个部分中发现了错误，则它可能会阻止整个发行过程。可能会保留新功能，等待集成，测试和发布错误修复。
小而专注的团队。微服务应足够小，以使单个功能团队可以构建，测试和部署它。小团队规模可提高敏捷性。大型团队的生产力往往较低，这是因为沟通速度较慢，管理开销增加并且敏捷性降低了。
小代码库。在整体应用程序中，随着时间的流逝，代码依赖关系趋于混乱。添加新功能需要在很多地方触摸代码。通过不共享代码或数据存储，微服务体系结构最大程度地减少了依赖性，从而使添加新功能更加容易。
技术融合。团队可以通过适当地混合使用各种技术来选择最适合其服务的技术。
故障隔离。如果单个微服务不可用，只要将任何上游微服务设计为正确处理故障（例如，通过实施断路），就不会破坏整个应用程序。
可扩展性。服务可以独立扩展，使您可以扩展需要更多资源的子系统，而无需扩展整个应用程序。使用Kubernetes或Service Fabric等编排器，您可以将更高密度的服务打包到单个主机上，从而可以更有效地利用资源。
数据隔离。执行架构更新要容易得多，因为仅会影响单个微服务。在单片应用程序中，架构更新可能变得非常具有挑战性，因为应用程序的不同部分可能都接触相同的数据，从而使对架构的任何更改都具有风险。
挑战性
复杂性。与等效的单片应用程序相比，微服务应用程序具有更多的活动部件。每种服务都比较简单，但是整个系统整体来说更复杂。
开发和测试。编写依赖于其他依赖服务的小型服务与编写传统的整体或分层应用程序所需要的方法不同。现有工具并非总是设计为与服务依赖项一起使用。跨服务边界进行重构可能很困难。测试服务依赖性也具有挑战性，尤其是在应用程序快速发展时。
缺乏治理。构建微服务的分散式方法具有优势，但也可能导致问题。您最终可能会遇到太多不同的语言和框架，从而使应用程序变得难以维护。在不过度限制团队灵活性的情况下，制定一些项目范围的标准可能很有用。这尤其适用于横切功能，例如日志记录。
网络拥塞和延迟。使用许多细粒度的服务可以导致更多的服务间通信。同样，如果服务链依赖关系太长（服务A调用B，调用C ...），则额外的延迟可能会成为问题。您将需要仔细设计API。避免使用过多的API，考虑序列化格式，并寻找使用异步通信模式的地方。
数据完整性。每个微服务负责自己的数据持久性。结果，数据一致性可能是一个挑战。尽可能采用最终的一致性。
管理。要成功使用微服务，需要成熟的DevOps文化。跨服务的相关日志记录可能具有挑战性。通常，日志记录必须将单个用户操作的多个服务调用关联起来。
版本控制。对服务的更新不得破坏依赖于该服务的服务。可以在任何给定时间更新多个服务，因此，如果不进行仔细的设计，则可能存在向后或向前兼容性的问题。
技能集。微服务是高度分布式的系统。仔细评估团队是否具有成功的技能和经验。
最佳实践
围绕业务领域对服务进行建模。
分散一切。各个团队负责设计和构建服务。避免共享代码或数据架构。
数据存储应对拥有数据的服务专用。为每种服务和数据类型使用最佳存储。
服务通过精心设计的API进行通信。避免泄漏实施细节。API应该为域建模，而不是服务的内部实现。
避免服务之间的耦合。耦合的原因包括共享数据库架构和严格的通信协议。
将跨领域的问题（例如身份验证和SSL终止）卸载到网关。
将域知识置于网关之外。网关应在不了解业务规则或域逻辑的情况下处理和路由客户端请求。否则，网关将成为依赖项，并可能导致服务之间的耦合。
服务应具有松散的耦合和较高的功能凝聚力。可能会一起更改的功能应一起打包和部署。如果它们驻留在单独的服务中，那么这些服务最终将紧密耦合，因为一项服务的更改将需要更新另一项服务。两个服务之间的交流过多可能是紧密耦合和内聚力不足的征兆。
隔离故障。使用弹性策略可防止服务内的故障级联。请参阅弹性模式和设计可靠的应用程序。