后端开发教程 - Java、Spring Boot 实战 - msg200.com
我应该使用微服务架构吗？
一片混乱
流沙
微服务和分布式系统
如有疑问，请澄清
什么是微服务？
重点是什么？
穿上我们的大男孩/女孩建筑裤
一个实际的例子
一些提醒和附注
进化架构
关于 UI 问题……
复合 UI
并非我所了解的微服务
尺寸并不重要……真的重要吗？
结论
需要幫忙？
保持联系
微服务是一个很大的话题，但它并不是一个非常精确的话题。
Martin Fowler 表示同意：
虽然这种建筑风格没有精确的定义……
一片混乱
深入研究微服务主题，您很快就会发现存在许多不同的观点。
例如，Martin Fowler 建议您不应该使用微服务架构来启动新系统。
然而，他的同行 Stefan Tilkov 建议你应该始终从微服务架构开始。🤔
Udi Dahan 认为，微服务的定义仍然过于细粒度，并且可能缺乏对实际边界和 UI 考虑的关键关注。
我们应该相信谁？
流沙
让我们面对现实：科技界的观点总是在变化，而且往往不像我们所希望的那样非黑即白。
“最佳实践”往往每隔几年就会发生变化。
我们曾认为 DRY 是自切片面包发明以来最好的东西。现在我们却被告知，共享代码可能是人们所能做出的最具破坏性的架构决策之一。
那么微服务呢？
微服务和分布式系统
大多数关于微服务的报道都是肤浅、模糊和矛盾的。
然而，遗憾的是，没有太多信息概述微服务风格是什么以及如何实现它。
为了强调这一事实（这是一个非常重要的事实），让我们来看看InfoQ 的 2019 年架构和设计趋势报告。
请注意，微服务处于“晚期大众”阶段。这意味着微服务在业界相当普遍。
现在，查看标有“早期采用者”的第二部分。看到那个叫做“正确构建的分布式系统”的部分了吗？
作为一个行业，总体来说，我们一直在做微服务，但做得并不好。
如有疑问，请澄清
但是，让我们看看是否应该使用微服务架构作为一般概念。
我们首先会问一些关于微服务的基本问题：
- 什么是微服务？
- 什么是微服务架构？
- 我的架构中应该有多少个微服务？
- 它们应该有多大？
- 为了拥有微服务架构，我的整个架构是否应该由微服务组成？
- 那么宏服务呢？有这种东西吗？
- 如果有的话，它们比微服务更好还是更差？为什么？
- 我的 UI 怎么办？它还是一个庞大的单页应用吗？
- 我可以使用基于 MVC 的 Web 框架并仍然使用微服务吗？
- 他们应该有多自主？
- 这一切与云有何关系？
- Serverless 是一种微服务架构吗？
- 如果我确实有服务器，我还能拥有微服务架构吗？
这些问题看似简单，但只要深入探究，就会发现答案并非如此简单。
什么是微服务？
Martin Fowler 承认微服务并没有一个精确的定义。然而，他试图阐明微服务可能是什么样子的：
...服务可独立部署且可扩展，每个服务都拥有牢固的模块边界，甚至允许使用不同的编程语言编写不同的服务。它们也可以由不同的团队管理。
根据这个定义，您将看到的典型微服务架构将如下所示：
每个微服务都可以独立部署和扩展。它们作为独立进程运行，并通过网络进行通信。每个微服务都有自己的数据库。
好的。现在来看这个例子：
这是一种常见的架构，你会发现在那些已经盈利一段时间的真实公司中。
想象一下，每个单体应用程序都处理不同的领域，如运输、计费等。
这里明显的问题是，共享数据库可能导致各种问题，而这些问题通常可以通过适当的封装来避免。
一些公司所做的不是将他们的系统重新架构为微服务集合，而是对他们的整体应用适当的封装（通过领域驱动设计的有界上下文）。
重点是什么？
我有一个问题，它揭示了微服务的一般概念：
微服务图和正确封装的整体图之间有什么区别？
唯一的区别是微服务架构图在整个系统内共享用户界面。
我觉得奇怪的是，在大多数关于微服务的文章和讨论中，几乎没有提到 UI 的问题。
鉴于微服务的典型定义和解释，封装的整体和“微服务”之间的区别并不明显。
（如果我们从一些整体式应用中删除 UI，为每个应用添加一个 REST API，并为它们提供共享的 UI，会怎么样？这听起来与您将看到的典型微服务架构图非常相似……）
毕竟，转向微服务的最大原因是让不同的跨职能团队能够完全拥有自己的产品。
考虑到适当有界的单片方法，这种方法非常有效：
但是，一般的“微服务架构”在这方面存在不足：
谁负责 UI？所有人？还是没人？创建一个新团队？
穿上我们的大男孩/女孩建筑裤
事实是，软件系统比我们想象的更加流畅和动态。
这比我们想象的要难。
软件架构涉及采用许多较小的想法并将它们以适合您的用例的方式组合在一起。
这并不是要把一个总体想法应用到我们的整个系统中。
一个实际的例子
想象一下拥有现有遗留系统的企业。
这种单体系统通常变更起来风险很大。业务部门要求一些新功能能够更快地上市。
我们是否应该将整个系统重写为微服务的集合？
通过拥有专用业务功能的集中封装服务来添加新功能更有意义。
这将更像是一种软件架构的进化方法（继续阅读）。
一些提醒和附注
再说一遍，事情没那么简单。我们必须思考现有的系统，思考我们期望业务在不久的将来发展到什么程度，并运用技术和方法，确保业务持续增长并盈利。
浪费时间将整个系统重写为微服务可能效果不太好（1、2、3、4）。
糟糕的团队总会创建糟糕的系统——很难判断微服务在这种情况下是否会减少混乱或使情况变得更糟。
并且不要忘记，我们大多数人甚至都没有正确地构建分布式系统：
对“微服务”架构风格的认识可能正在进入后期大众阶段，但“正确设计分布式系统”以及针对反应性和容错性进行设计等相关主题在采用曲线上还不算太远。
进化架构
这种灵活且更具适应性的软件架构方法有时被称为演进式架构。在我看来，这只是一种简单、负责任的软件架构方法。
InfoQ 将这种方法列为“早期采用者”阶段。这表明大多数公司仍在“摸索”微服务。
演进式架构是一个广泛的原则，即架构在不断发展变化。虽然它与微服务相关，但它并非微服务的另一个名称。例如，你可以朝着微服务的方向演进，也可以远离微服务。
https://www.infoq.com/podcasts/refactoring-evolutionary-architecture/
自 2011 年以来，进化架构一直属于 ThoughtWorks 技术雷达的“采用”类别。
这其实并不是什么新鲜事。
与传统的预先制定的、重量级的企业架构设计相比，我们建议采用演进式架构。它既能提供企业架构的优势，又能避免试图准确预测未来所带来的问题……我们提倡将决策推迟到最新的责任时刻，实际上，对于某些决策而言，这可能是预先制定的。
https://www.thoughtworks.com/radar/techniques/evolutionary-architecture
对我来说，这听起来像是在做负责任、合理和智能的软件架构。
如果您对此感兴趣，我建议您观看Randy Shoup 的这场 16 分钟的讨论。
零步是解决真正的客户问题，解决真正能给客户带来利益的问题，可能是重新实现已有的东西，或者理想情况下是实现一些在整体系统中难以实现的新功能。
首先，用新的方式去做，你试图做的就是从第一次转变过程中不可避免的错误中吸取教训，对吗？你以一种相对安全的方式去做，但同时，你最终也会获得真正的益处。
正如兰迪后来指出的那样，如果没有真正的理由改变系统的某些部分，那么保持其原样是完全可以的。
这个网站上仍然有一些页面是基于 V2 架构的，仅仅是因为它们还能用，每天有 10 万次点击量，没什么大不了的，迁移起来也不太麻烦，投资回报率也不太高。所以，它们就保留了下来，而且很乐意地保留了下来。
关于 UI 问题……
您可能对大多数微服务架构图中出现的共享 UI 感到好奇。
有办法解决这个问题吗？
是的，有。但事情并不像我们想象的那么简单。
它归结为允许每个微服务拥有自己的 UI 组件。
这使得各个团队可以拥有整个堆栈。
复合 UI
当我们有一个需要显示来自多个服务的数据的 UI 时会发生什么？
解决方案是组合这些服务拥有的多个 UI 组件。
很多情况下，复合 UI 比上图复杂得多。但这只是个起点，可以帮助您理解这种方法的最终结果。
并非我所了解的微服务
大多数人在说“微服务”时想到的并不是这个。微服务通常没有拥有其拥有的 UI 组件的概念。
在讨论这个问题时，Udi Dahan 举了产品价格的例子。Udi 指出，特定服务需要拥有自己的 UI。否则，我们就破坏了封装性。
这样，服务边界之外的任何代码都不会知道产品价格的概念，因此不会与之耦合。
...我真的不明白[微服务]最终如何能够拥有这种级别的数据所有权。
尺寸并不重要……真的重要吗？
你可能会听说微服务的代码量应该在 1000 行或更少左右。至少我以前听说过。
然而，微服务需要拥有给定业务环境的数据、行为和 UI。
作为开发人员或架构师，我们不应该随意决定我们的服务应该有多大。这完全取决于我们正在建模的业务环境。
关于失业保险所有权的问题，Udi Dahan 指出：
您会看到，服务规模并不是那么小，而且数量可能也不是那么多。
Udi 被认为是构建分布式系统领域最受尊敬的专家之一。多年前，他就指出我们的做法是错误的。
微服务可能过于“微”了，因为它们不尊重实际业务环境的边界。与其关注规模，不如关注合理的边界（这个话题留到以后再说）。
结论
您应该使用微服务架构吗？
不。
您应该做对您的业务有意义的事情。
例如，您的企业可能想要打造需要快速上市的新产品。
您可以将这些新产品添加为完全独立的整体，通过事件消息相互通信以保持松散耦合。
它们可以构建为微服务，并通过 HTTP REST 调用或事件消息传递重新集成到现有系统中吗？
也许贵公司有现成的解决方案可以购买？您可以在其基础上构建自定义 API，以便与现有系统集成。
有些情况下需要将现有系统拆分成多个独立的组件。这些组件可能是微服务。
或者，您可以在单片系统中使用类似插件组件的系统。
（我曾写过一篇关于使用 .NET Core 构建模块化整体的方法。）
我们甚至还没有讨论团队技能/能力、项目管理风格、组织影响等因素。这些都是影响软件架构的因素！
综上所述：
这取决于。
但是，对于规模较小的组织，有相应的指导方针吗？当然有。再说一遍：所有这些事情的核心要点是“只解决你实际遇到的问题”。
需要幫忙？
我帮助 Saas 企业提高其整体敏捷性和新产品和新功能的上市时间。
我还为使用 .NET Core 的团队提供指导，他们需要帮助构建 Web API、框架迁移、改进开发流程等。
另外，请查看我的关于如何保持代码健康的书！
保持联系
不要忘记通过以下方式与我联系：
文章来源：https://dev.to/jamesmh/should-i-use-a-microservices-architecture-4751