最终，我们放弃了微服务
这几年，有无数的中小团队在微服务上陷入了挣扎。微服务有好处但也存在弊端和风险，业务不断发展，微服务也更加复杂，一些企业权衡利弊后甚至选择了退回单体架构。在这个专题里我们总结了一些放弃微服务的实践案例。
从单体到微服务再合并，我们找到了平衡点
微服务的一些好处是切实存在的，但它的一些缺点和潜在风险也不可忽视。
我们为什么停用微服务？
从单体迁移至微服务，再从微服务迁回单体应用，本文讲述了 Botify 使用微服务的失败故事。
Istio 为什么不再使用微服务?
微服务并非完美的应用程序架构
为什么 Segment 从微服务回归单体
作者讲述了一个警示性的故事，着重指出了架构决策中取舍评估的重要性。
这些公司为什么放弃微服务？
在微服务受追捧时，Uber、Botify、Segment 等公司却放弃微服务，这是为什么？
如何寻找最佳架构，单体架构还是微服务？
我们应该关注架构驱动力，以便于寻找系统的最佳架构。
放弃微服务，改用宏服务，Uber 这波什么操作？
Uber 支付体验平台放弃了微服务，转而使用了宏服务，这一消息在网友中引起了热议。一向是微服务积极分子的 Uber 为什么突然改用宏服务了？以“简单”著称的微服务为什么又变得难以维护了呢？
Uber 从单体架构转向微服务架构
Uber 最初采用单体架构构建了一款仅服务于一座城市的产品。但随着 Uber 的迅速发展、核心领域模型的扩大，组件成了紧耦合的，持续集成成了很大的负担。新增特性、Bug 修复、技术债务解决，全都在单个库中进行，这极其困难。因此，他们决定将单个代码库拆分成多个代码库，由单体架构迁移到微服务架构。近日，Uber 官方网站介绍了这一迁移过程。
为什么 Segment 会从微服务退回单体架构？
Segment 的 Alexandra Noonan 写了一篇文章讲述了一段经历：他们从单体架构迁移到微服务，之后发现迁移带来了诸多问题，经过思考后又退回和原来不同的单体架构，并获益良多。
微服务架构何去何从？
微服务架构模式经过 5 年多的发展，在各行各业如火如荼地应用和实践。如何在企业中优雅地设计微服务架构？是企业面对的一个重要问题。本文将讲述微服务架构 1.0 设计与实践以及面临问题和破局，最后讲述微服务架构 2.0 设计与实践等方面，尝试去回答这个难题。
微服务架构陷阱：过渡设计和设计不足
在这篇文章里，我将简要地介绍在设计微服务架构时需要注意的问题。如果实施得当，就会获得自治能力和灵活性，但同时也会带来通信延迟和部署及托管成本。这篇文章并不是一个高级指南，我只是希望能够在你们决定采用微服务架构时帮你们做出更好的判断。
最终，我们放弃了微服务
经过一个月调研，很多问题没办法解决，我们选择放弃
醒醒！你不是真的需要微服务
2020 年，很多技术人可能都已经迷醉在了微服务的成功故事中，但现实很骨感，微服务也不是“灵丹妙药”。本文想给现阶段“狂热”的微服务泼泼冷水、降降温，也许你就会发现，你并不是真的需要微服务。
微服务失败的 11 个原因
微服务是流行的软件架构，大家都喜欢上微服务，这里有微服务失败的 11 个原因，看看你中招没？
戳破微服务的七大谎言
在这篇文章中，作者将揭穿工程师们关于微服务所讲述的七大谎言，以及为什么它可能是一种反模式。
微服务带来的心理阴影
单体架构不是那么苦，微服务架构也不那么香，中台架构也不甜。
微服务到底该多大？如何设计微服务的粒度？
在修改系统之前，我们通常并不一定知道微服务划分的粒度是否合适。
京公网安备 11010502039052号 | 产品资质
