江苏龙网

  1. 主页 > 生活百科 > >

微服务是个坏主意吗？( 二 )

微服务


与巨石时代形成鲜明对比的是，在铁板一块时，变化尽管规模较大，但具有一定的可预测性 。
工作流程是线性的，那么部署呢？好吧，他们感觉更受控制了 。
如果你曾经尝试通过一串 Slack 消息来传达一个复杂的想法，你就会欣赏直接沟通的益处 。与此类似的，在单体架构中，模块之间的进程内通信的简单性是直接、无缝的，并且通常被认为是理所当然的 。没有网络调用，没有延迟，没有丢失请求 。一切都在应用程序的范围内正常工作 。
使用微服务 ， 服务间通信感觉就像试图与分布在各大洲的团队成员进行 Discord 语音聊天，每个人都在与自己的互联网困境作斗争 。
当然，这是可行的，但这些小问题会让你怀念一切都在一个屋檐下的时光 。当公司要求他们的开发人员回办公室坐班时，我理解了：它确实有它的好处，尤其是在即时沟通方面 。
5、权衡：我们得到了什么，失去了什么微服务的主要优势之一是能够专注于特定的功能 。我记得我被分配到一个专门负责用户身份验证的团队 。解耦的特性使我们能够完善机器中的一个齿轮 。
不久前 ， 我们的单体应用中的一个小模块故障导致了严重的中断 。对于微服务，每个服务都充当其隔离的故障点 。我见过一些特定微服务出现宕机的实例 ， 但多亏了架构，整个应用程序得以继续运行 ， 用户对此几乎没有感知 。
6、当单体更好时管理微服务感觉就像同时处理十几个Slack频道 。每个服务都有自己的日志记录、监视和部署过程 。相比之下，单体架构有一个固定的流程 。
微服务通常意味着多个数据库 。虽然这看起来很棒 ， 但确保数据一致性却是一场噩梦 。在单体架构时代，一个数据库意味着一致性 。这就像在 Discord 中有一个线程 ， 每个人都在更新 。我经常发现自己怀念这种统一性提供的便利 。
然后是整体调试 。
还记得尝试通过相互连接的微服务跟踪bug吗？这就像追溯无数的 Discord 对话来找到一条消息 。但在单体架构的设置中，错误日志是集中的，因果关系更加清晰 。
7、总结：微服务之旅中的反思当我回顾自己在微服务领域的尝试时，我发现这条道路充满了挑战、得失和可以从中学习收获的宝藏 。以下是我在微服务之旅中获得的3个主要收获 。
1） 明智地接受复杂性
深入微服务不仅仅是一个技术决策——这是对复杂性的承诺 。有时，我们会觉得自己只是为了顺应潮流而打破了一个体系 。并非每个应用程序都需要由相互连接的服务组成的网络 。正如Sam Newman在《构建微服务》中提到的那样，架构需要一定的先决条件，如果没有这些先决条件 ， 它可能会矫枉过正 。
2）灵活性是有代价的
是的，微服务承诺了灵活性，但要实现这一点，也需要付出沉重的代价——不仅在基础设施方面，而且在认知负荷方面 。每项服务都有自己的领域 ， 需要专门的关注 。
3）没有放之四海而皆准的方法
架构决策不能脱离业务需求 。灵活的初创公司的需求与传统的企业应用程序截然不同 。虽然经典案例研究（例如.NETflix 著名的微服务转型）很有启发性，但必须认识到，适用于一个人的方法不一定适用于所有人 。
变身为技术弄潮儿可能很诱人 。成为科技领域重大变革的组成部分有一定的吸引力 。但作为代码的守门人，我们需要抵制盲目接受趋势的诱惑 。批判性评估、理解趋势背后的“原因”，并权衡其与我们的特定背景的相关性至关重要 。
Slack 消息、Github 存储库和 Discord 讨论已成为我们许多远程开发人员的新饮水机 。在各种噪声中 ， 让我们记住定期聚焦 ， 反思我们的选择，并确保我们不只是追逐趋势 ， 而是有目的地制定经得起时间考验的解决方案 。
参考链接：https://medium.com/@PurpleGreenLemon/was-microservices-a-bad-idea-5e52edee1cff




推荐阅读


上一篇：如何使用Python构建OTP验证系统？

下一篇：LangChain实战：大语言模型理解代码库