内容
什么是软件架构？
软件架构的重要性
什么是微服务架构？
微服务架构的优缺点
其他突出的软件架构模式
构建微服务架构的最佳实践
计划构建微服务架构？
什么是软件架构？
软件架构模式的模式
软件架构本质上是任何给定软件系统的结构。它用于提供整个系统的图形表示，有助于开发人员。
通常有多个组件，每个组件都解决一个或多个功能。
上面的软件架构图示例显示了这些组件如何相互交互。在“软件架构”中阅读更多相关信息。请记住，上图只是一个基本示例。
我们称之为软件架构的示意图只是一种视觉表示。每个系统图都显示了软件架构师决定的一系列设计原则，以确保最佳的整体系统功能。做出架构决策是为了确保最佳的安全性、性能、可管理性等。
这些设计原则、架构决策和示意图都是软件架构的组成部分。它们共同使系统能够满足其业务、运营和技术目标。在此 Techopedia 软件架构定义中阅读更多内容。
软件架构的重要性
软件架构对于产品的成功极其重要。有几个原因。
第一组决定
在“软件开发生命周期”（SDLC）期间，开发团队在软件架构的创建过程中做出与系统相关的关键决策。在此过程之前，将仅概述业务需求。
如您所知，确保第一组决策正确无误，将使您的项目处于最佳状态以顺利运行。另一方面，如果这些决定不正确，您的项目几乎肯定会遇到严重的问题。在“良好软件架构的重要性”中阅读更多相关信息。
视觉呈现的交流工具
软件架构是一种工具，通过提供示意性表示来帮助沟通，这些表示显示与改进核心功能相关的底层决策。做对了，您的所有项目利益相关者以及您的开发团队将准确了解您的产品将如何运作。
可重用性
软件架构有助于持续开发，特别是对于未来的项目。由于您已经制定和实施了一次架构决策，并拥有示意图，因此可以在未来的项目中重复使用或扩展这些决策。
这意味着您可以为新产品重用大部分核心结构，因为只有开发工具、编程语言等会有所不同。没有良好的软件架构，项目或产品可能会失败。在此 Quora 问答主题中阅读更多相关信息。
什么是微服务架构？
单体架构和微服务架构差异的示意图
微服务架构模式帮助开发人员创建多个较小的程序，而不是一个大程序。一个大程序通常很难维护，此外，添加新功能也很困难。使用微服务架构，程序员为每个功能创建一个小程序。添加新功能只需要创建另一个小程序。
视频点播平台 Netflix 是这种架构模式的一个很好的例子。正如您所料，Netflix“用户界面”(UI) 中的每个部分都是不同的服务。实际上，UI 就像是不同网站的集合，尽管它看起来只是一个。阅读“微服务架构（示例和图表） ”了解更多详情。
微服务架构的优缺点
这种模式有很多优点：
当企业提供彼此明显分离的功能时，这种架构模式可以使他们的应用程序具有高度可扩展性。
个别服务可能有不同的需求概况，因此，企业将为这些个别服务实施扩展策略。这有助于优化和确定资源的优先级。
如果您使用这种架构模式，您会发现阅读和理解您的代码库会容易得多。
维护应用程序更容易。
单个微服务可以单独部署。您只部署已更改的微服务，而不是整个应用程序。这减少了在部署过程中花费的时间和精力。
您发现调试应用程序更容易，因为您无需查看大型应用程序的多个层。
微服务架构模式可以更轻松地隔离故障。
如果您使用微服务架构模式，您可以构建更具弹性的服务，这会提高您的应用程序的容错能力。
如果您使用微服务架构，则可以提高可重用性。在此模式中，您可以围绕业务功能构建和组织微服务。当与其他业务功能存在共性时，您可以以最少的更改重用您之前开发的微服务。这种重用有助于降低您的开发成本。
在“什么是微服务？”。
也有缺点：
如果我们不能清楚地将服务彼此分开，这种模式会增加复杂性。
如果多个服务使用相同的任务，则此模式会对性能产生不利影响。
如果由于网站不同部分的页面速度不同，微服务过多，用户可能会发现 UI 混乱。如果您使用太多不同的编程语言来开发不同的微服务，那么您的应用程序将更加难以维护。
如果您使用微服务架构，集成测试可能会很困难。如果您的组件位于其他系统/环境中，那么您会发现很难设置端到端的集成测试环境。
您需要仔细定义微服务与其他服务交互的接口。如果您有太多由不同团队开发的微服务，那么定义此类接口可能会很困难。不同的微服务将相互依赖输入。不同的开发团队需要清楚地了解其他微服务可能使用的接口，因此，沟通是关键。
微服务架构实现的一个突出例子
想看看微服务架构在起作用吗？好吧，Netflix 就是您的最佳选择！这家流行的流媒体服务提供商充分利用了这种架构模式。
Netflix 仍在经历高速增长，然而，该公司最初难以跟上它的步伐。它有一个单体架构，它的数据中心与此保持一致。Netflix 无法以足够快的速度建立足够数量的数据中心来跟上其令人印象深刻的增长。
同年，一个模块代码中缺少一个分号导致 Netflix 网站瘫痪。该网站关闭了几个小时，需要一个大型工程团队的共同努力才能恢复。当 Netflix 不得不进行故障排除时，它总是不得不聘请一个由多个领域组成的大型工程团队。嗯，这就是使用单体架构的巨大应用程序的缺点！
Netflix 于 2009 年开始转向 AWS 云微服务架构，当时微服务架构模式并不流行，甚至连“微服务”这个词都没有使用。
该公司于 2009 年首次迁移了一款非面向客户的应用程序，并且进展顺利。随后，Netflix 将其网站的几个面向客户的功能转移到了 AWS 云微服务架构中。到 2011 年 12 月，Netflix 完成了搬迁。
就本月的情况而言，Netflix 微服务架构中的 API 网关每天处理 20 亿次 API 调用！您可以阅读“为什么不提及 Netflix 就不能谈论微服务”以了解有关此转变的更多信息。
其他突出的软件架构模式
当我们回顾其他软件架构模式的特征时，微服务架构的重要性变得更加清晰。
微服务架构还有其他四种关键模式：
分层架构
这是最常见的软件架构模式。大多数业务应用程序将信息存储在数据库表中。这种模式在层中有代码。最顶层接受数据。然后数据导航到最底部的层，即数据库。
大多数关键框架（如 Java EE）都使用这种模式。分层架构提供了一些优势，例如，应用程序易于维护，测试更容易。在“大型企业 Java 项目架构”中阅读更多相关信息。
缺点是代码量大且无组织，其中大部分只在层之间传递数据，不执行任何业务逻辑。这会影响产品的性能。
事件驱动架构
许多用例涉及仅在有数据要处理时才执行的程序。在事件驱动架构的情况下，中央单元接收所有数据输入。特定的数据输入是事件。然后中央单元委托适当的组件处理特定类型的数据。
并非所有模块都处理所有数据。这使得应用程序具有可扩展性，此外，开发人员可以轻松扩展系统以应对新事件。在“前 5 种软件架构模式：如何做出正确选择”中阅读更多相关信息。
有一些缺点。当模块相互影响时，测试变得更加困难。如果多个模块处理同一个事件，它会使错误处理复杂化。由于消息传递开销，系统可能会变慢。
微内核架构
常用工具有一组用户重复执行的任务。著名的“集成开发环境”(IDE) Eclipse 就是一个这样的例子，它具有可重复的任务，如打开文件、编辑文件等。
微内核架构使用微内核来包含这些基本功能。我们可以将其上的所有其他内容视为“插件”。这种模式非常适合流行的工具，因为它可以提高性能。但是，很难定义常见的任务。在“软件架构：您需要了解的 5 种模式”中阅读更多相关信息。
天基建筑
基于空间的架构的目标 是在高负载时为 Web 应用程序提供健壮性和稳定性。大多数网站都是围绕数据库构建的，因此，它们依赖于数据库来处理负载。
使用基于空间的架构，软件架构师将处理和存储拆分到多个服务器中。数据和服务调用分布在节点之间。这有助于避免数据库在高负载情况下崩溃。请注意，测试整个系统可能很困难，因为模拟负载条件可能很棘手。
构建微服务架构的最佳实践
微服务架构实现的最佳实践
寻找最佳微服务架构
概述您的微服务
领域驱动设计
让每个人都加入
使用 RESTful API
为特定的微服务建立团队
设置服务器和数据存储环境
文档 API
使用最好的 DevOps 工具包
监控是关键
最佳实践 #1：确定微服务架构是否符合您的要求
Amazon、Twitter、eBay 和 PayPal 是成功实施微服务架构设计的组织的例子。这是一种流行的模式，然而，这并不意味着它对你有用。
如果您不能将您的 Web 应用程序分解为提供价值的功能，那么微服务架构对您来说就没有意义了。阅读“模式：按业务能力分解”以获得更多见解。
最佳实践#2：定义您的微服务
您需要明确区分业务功能、服务和微服务。如果没有这个，您可能会构建过大的微服务。这是一种不完整的形式，您将看不到使用微服务方法的任何好处。
另一方面是创建过多微服务的可能性。这将导致您的架构过度碎片化。请记住，要管理微服务架构，您需要一个成熟的运营团队。在“微服务权衡”中了解它。
如果微服务太多，运营管理成本会很高。您将看到运营成本的激增掩盖了您从微服务中获得的收益。
最佳实践#3：使用“领域驱动设计”（DDD）来设计微服务
虽然这一步与定义微服务的练习密切相关，但它更进了一步。在这里，您可以围绕您的业务领域设计微服务。让我们再次回顾 Netflix 示例。他们从不同的服务器运行他们的内容交付和不同的跟踪服务。
“领域驱动设计”(DDD) 是一种设计原则，它使用实用的规则和思想来表达面向对象的模型。它帮助软件架构师了解不同的业务领域，因此，他们可以专注于构建业务可以很好理解的微服务架构。在“ DDD 101 — 5 分钟之旅”中阅读更多相关信息。
最佳实践#4：尽早获得组织领导和团队的支持
实现微服务架构设计不仅仅是一个技术决策。这种转型代价高昂，而且影响不仅限于内部开发团队。从单体架构过渡是一个漫长的项目。组织中的高级管理人员必须为此投入资金。
对您的开发团队的影响将是巨大的。到目前为止，您的团队一直在使用端到端测试过程来测试整个系统，以防出现增强。您现在需要围绕微服务对系统进行模块化。这需要文化转型。
转型将有助于您的业务敏捷性，因为它将促进持续交付。但是，团队必须完全接受转型。阅读我们的指南“敏捷帮助变革管理的 5 种方式”，了解如何有效地帮助这种转变。
最佳实践 #5：最佳地使用 RESTful API
如果您优化使用 RESTful API，微服务架构模式可以提供重要的价值。RESTful API 提供了许多优点，例如，您不需要在客户端安装任何东西。您不需要 SDK 或框架，因为使用 API 服务的 HTTP 请求就足够了。在此 Quora 问答主题中阅读有关 RESTful API 优势的更多信息。
RESTful API 领域的专家 Leonard Richardson 提出了 REST API 使用的成熟度模型。为了从您的微服务架构中实现最佳价值，您应该尝试达到此成熟度模型的最高水平。阅读“微服务架构的 10 个最佳实践”以获得更多见解。
最佳实践 #6：围绕微服务组织团队
您需要建立不同的团队来处理不同的微服务。这些团队应该被赋予足够的权力来处理他们的微服务。但是，所有团队都应该跨职能并了解整个项目计划。
每个团队都应该具备构建云原生应用程序的必要技能。每个团队都需要业务分析师、开发人员、测试人员和 DevOps 工程师。每个团队都应该有自己的项目经理 (PM)。我们的指南“如何建立Scrum开发团队？”可以帮助您组织这些团队。
最佳实践 #7：为每个微服务提供单独的数据存储
每个微服务都应该为其数据存储做好准备。每个微服务都应该完全拥有自己的数据。当然，数据可以在微服务之间共享，但是，这应该通过 API 进行。
如果多个微服务共享同一个数据存储，这会导致服务之间的耦合。这将大大违背微服务架构的目的。在“ Top 5+ 微服务架构和设计最佳实践”中阅读更多相关信息。
最佳实践 #8：基于领域设计 API 并很好地记录它们
充分注意基于业务领域设计 API。很好地记录 API。考虑使用Swagger 之类的工具。我们有一个指南“如何为您的移动应用程序构建 RESTful API？”您可以咨询。
最佳实践 #9：使用好的 DevOps 工具集
到目前为止，您应该已经将微服务设计得足够好，可以独立部署它们。为了从这些微服务中实现最佳价值，您需要自动化构建和部署管理。因此，您将需要一套良好的 DevOps 工具。
用于部署自动化的 Jenkins 和用于容器化的 Docker 是一个很好的组合。但是，如果您需要更多示例，请阅读“ 2019 年的 10 个最佳 DevOps 工具”。
最佳实践 #10：投资于监控
如果您使用的是单体架构并正在过渡到微服务架构，则必须解决日益增加的复杂性。对性能和动态环境的需求增加需要更高级的监控。
一个好的监控解决方案应该解决资源分配的持续变化。这样的解决方案应该将从监控中收集的数据存储在中央数据库中。它产生的洞察力应该揭示应用程序的动态特性。
每个微服务都应该使用监控代理。监控系统应支持根本原因分析。阅读更多关于它在“成功微服务设计的 5 个基础”中的重要性。
部署微服务架构时的关键考虑因素
可以看到，部署微服务架构是一个涉及到的项目。在进行此类项目时，请牢记以下注意事项：
管理依赖
您需要在微服务架构中以不同于单体应用程序中的方式管理依赖项。微服务架构涉及每个独立运行的服务。但是，一个微服务可能需要访问系统的其他部分。这就是复杂性出现的地方。仔细考虑依赖关系。寻找具有所需知识的建筑师
架构师将在实施微服务架构中发挥关键作用。你需要一个称职的建筑师。架构师可能需要使用事件驱动的聚合来实现此架构，这需要适当的后端相关专业知识。
请记住，微服务架构中的微服务是分布式系统。因此，架构师需要具备这方面的良好知识。
此外，架构师需要实现从多个数据存储中检索数据的查询。在微服务架构中，这将比单体应用更复杂。该项目可能会使用“事件溯源”模式，这会增加复杂性。架构师可能需要在此处使用“通用查询职责分离”(CQRS) 模式。
在某些情况下，架构师可能需要使用“断路器”模式。这可以帮助多个服务在为请求提供服务时进行协作。一个服务可能会同步调用另一个服务。此其他服务可能会停机，或者，它可能会遇到高延迟。“断路器”模式可防止此类问题影响其他服务。
负载平衡恰好是架构师需要足够经验的另一个领域。它有助于微服务在管理系统负载的同时保持安全性和可用性。
开发人员可能会在创建微服务时对要实现的端点数量感到困惑。知识渊博的软件架构师可以在这里发挥很大的作用，因为他/她知道端点的数量取决于服务的类型。
- 使用正确的工具和框架，如“Spring Boot”
使用正确的开源工具可以极大地帮助实现微服务架构。幸运的是，您可以利用丰富的开源工具生态系统。
例如，您可以使用流行的开源框架“Spring Boot”轻松创建微服务。以下是此类工具的更多示例：
API开发的邮递员；
用于消息传递的 Amazon Simple Queue Service (SQS)；
用于监控的 Logstash；
用于部署的 Kubernetes。
GitHub 在这里值得一提，尽管它不是完全开源的。这有助于您进行版本控制和源代码管理。
- 为可扩展性设计微服务
在设计微服务时，可扩展性是一个关键因素。无论是创建新服务还是增强现有服务，都需要注意这一点。为此，您需要考虑各种方法和技术。
一个很好的例子是缓存。请记住遵循正确的教程在微服务架构中实现它。异步消息传递使您能够在构建微服务时提供更好的可扩展性。
- 处理认证和授权
处理用户身份验证和授权在微服务和单体应用程序之间差异很大。您需要非常了解这些差异的架构师和开发人员。
例如，他们需要准确地定义有界上下文。这将帮助他们定义具有大量粒度的用户授权。
再举一个例子。您的团队将需要使用令牌进行用户身份验证。存在各种类型的令牌，例如“JSON Web 令牌”(JWT)。近年来，这种开放标准的代币越来越受欢迎。您需要了解此类现代标准的架构师和开发人员。
- 恰当地使用服务网格
有时您需要实现外部配置，如凭据以及微服务架构模式。您可能需要监控指标以了解应用程序的执行情况。考虑使用服务网格来管理服务之间的通信。
