我刚听说软件开发的未来是铁板一块
特斯拉有一些关于自动驾驶的坏消息(我有一个，我个人认为功能需要重新命名)。由于司机睡着了，已经发生了多起撞车事故。那是自动驾驶仪的错吗？我会说司机应该知道不要在405号高速公路上打盹(我用的是自动驾驶仪，相信我，我睡不着)。那么，我们是一起移除自动驾驶系统，还是学会正确使用它呢？
我们在软件架构方面处于相同的位置。人们欣然接受时髦的词汇和新的想法，好像他们可以解决一切问题。最近，这已经集中在微服务的使用和打破念珠菌的问题上。关于这一点，已经有了一些有趣的对话。如果你还没有看过，这是我指的其中一个对话。
前几天，一位非常体贴的同事让我注意到了这些(部分是为了通知我，部分是为了骚扰我)，我认为它们提出了一些非常有趣和有道理的观点。要真正理解这会带来什么帮助或伤害，我们不仅需要指出坏处，还需要为好的方面提供指导。让我们逐个来看看这些。
巨石就是未来，因为人们试图用微服务解决的问题并不真正符合现实。--凯尔西·海托华。
我相信这是百分之百正确的。“微服务”这个词已经被用作灵丹妙药，可以修复从功能失调的组织到设计糟糕的系统的各种问题。但是，我不认为另一种选择是回到“巨石”(队列不祥的音乐)。
我们正在处理期望与现实的范式。其中大部分可以归结为以下几点之一：
您可能在“Head First Design Pattern”一书中找不到这一点。
现在的代码库太糟糕了，你说“你知道我们应该怎么做吗？我们应该分手。我们会把它拆散，以某种方式找到我们从一开始就没有的工程学科。“。然后他们最终要做的是创建50个可部署的，但这实际上是一个分布式的巨石。--凯尔西·海托华
不幸的是，这太常见了。随着“神奇药丸”的出现，人们陷入了一种心态，即越小越快，反过来也越好。微服务不会修复一个坏的巨石。如果你做的千层面不好，不管你把它切成多少块，它仍然是不好的。
1.您正在复制另一个数据库…中的表(信息)，而没有将数据转换为新的数据(添加信息。
2.服务X在没有Y或Z的情况下无法工作，并且/或者您没有如何处理其中一个宕机的策略。
2.5奖金，很可能没有办法有意义地与服务脱钩。服务X可以“容忍”服务Y的故障，但如果没有服务Y，它将无法运行。
3.通过事件总线推送所有数据，以保持服务与…“同步”
Ruyn00bie(我喜欢这个名字)一语中的。这些都是在设计阶段必须考虑的因素。相互依赖的服务需要1)组合在微服务中2)使用队列模式以确保服务可以处理项目(当可用时)3)两个系统都可以坐在微协调器后面来处理错误情况。
事件总线是微服务基础设施的重要组成部分。但是，我认为它们应该只接受通知，而不是数据同步。
如果您从一个整体迁移到微服务，您必须将其作为重新评估和更新的机会。如果您处于这个决策点，那么很有可能您正在谈论的是一个已经存在了一段时间的系统。您不能将此视为剪切和粘贴编码练习，您必须回到第一步。
你需要对巨石有深入的了解。对你来说，这可能意味着你需要研究和理解你不熟悉的方面。您需要将其视为一组独立的子系统，而不是由较小部分组成的一个大系统。
这可能看起来并不重要，但你看待它的方式会产生巨大的影响。这个观点将决定你将会遇到的每一个决定。
例如，假设您有一个单一的应用程序，它是一个电子商务平台。你已经决定打破巨石了。您有几个选项：
越小越好-找到应用程序中的逻辑分割点，使用它们创建紧密绑定在一起的较小应用程序。部署这些并宣布胜利，您就是微服务大师！
越小越聪明-花点时间发掘一下独石的核心功能。请考虑这些是独立于生态系统的独立端到端应用程序。尝试扩展其处理更多用例的能力。部署无状态应用程序。
因此，在我们的示例中，我们可能会将事物分解为多个较小的部分，如购物车、产品、订单等。在这两种情况下，我们可能选择相同的分割点，但我们构建的内容将非常不同。在一种情况下，我们会将服务分开，但它们之间会存在紧密耦合。在第二个场景中，我们希望为每一个都创建一套完整的功能。
我是否可以将此微服务放在另一个架构中，而无需对其进行更改，并充分利用其所有功能？ - 是一名自我反思型工程师。
如果你的回答是肯定的，那么你一开始的观点是正确的。如果没有，则说明耦合太多，请重新开始。
很多东西都遵循微服务模式，比如你的车。你的车是由多个较小的部件组成的。其中一些组件，比如您的刹车，可以在您的汽车之外的其他汽车上使用(比如完全独立的微服务)。其他组件，如挡风玻璃，特定于您的品牌和型号(如相互依赖的微服务组件)。
这是一个仔细的平衡，需要计划才能适当地实施。就像任何好的架构一样，它永远不是固定的，并且会随着时间的推移而发展。
在架构图上单击SAVE的那一秒，它就已经是无效的 - A Wise Architect。
一个好的微服务解决方案首先要认识到，您要么是因为想要做出改变，要么是因为需要做出改变。如果需要的话，认清原因，避免像瘟疫这样的根本原因。
