卷首语：从微服务过去十年发展中，我们能学到什么？
作者：Tina
根据 Wiki 的说法，在 2011 年的时候，一群聚会中的架构师不知道如何命名自己正在探索的架构风格，于是他们使用了“微服务”这个词。这种架构风格，在得到正式命名之前也被一些人称为细粒度 SOA，即面向服务的架构，当时还存在着一些来自早期尝试者的负面反馈。但是没想到仅一年的时间，“微服务”这个词就开始因为技术演讲而流行了起来，变成了一个正式的名称。
这些早期实践者在宣传技术理念时，表示它可以使组织“走得更快”，从而快速交付业务价值，业界也开始达成一致，普遍认为它“显着提高了开发效率，使我们能够大胆思考并进行实质性的产品改进，并让工程团队能够安全地测试新技术。”
微服务就这么火了起来，迅速跨越“早期采用者鸿沟”成为了主流架构，一些早期参与者甚至觉得自己“创造了未来”。到了 2018 年左右的时候，InfoQ 还发布了“微服务成熟度状况”调查报告，报告显示接受调查的从业者对微服务总体持有非常积极的态度，似乎微服务已经成为了架构领域的“银弹”。
实际上，被称为“微服务之父”的 Fred George 在 2016 年就提出单靠微服务的实施不会给组织带来成功，必须识别和解决技术、流程和组织环境中阻碍业务敏捷性提高的因素。2020 年，他还以“Why I Wouldn’t Use MicroServices”为题发表了一次演讲，强调不同的问题需要不同的解决方案，但他发出的声音没有足够引起大家重视。
当采用微服务的组织增多，微服务本身也越来越复杂，大家在实践中踩的“坑”也就多了起来。虽然一直有人总结经验教训，但阻止不了微服务的全面采用。直到 GitHub 前 CTO 喊出了那句震惊业界的话：“全面微服务是最大的架构错误！”回头去看，过去的这些经验告诉我们，如果你的组织交付软件的速度太慢，那么采用微服务可能不会解决这个问题，而且还有可能会使情况变得更糟。因为一开始人们认为微服务与服务规模有关，但它更多是要解决开发人员基数太大、代码的开发和发布周期太长的问题。
我们受益于微服务带来的很多好处，也需要承担架构复杂性带来的成本，这中间存在着取舍。但就像前 Netflix 云系统总监 Adrian Cockcroft 所说的那样，架构可以复杂，也可以没那么复杂。可用的简单架构很多，选择适合自己的才最重要。这一切在于选择的人，因此不能全算是微服务的锅。
目录
热点 | Hot
15 年做不好的代码搜索，基于 Rust 重写引擎终于搞定：GitHub 声称能从此“改变游戏规则”
新必应整合 ChatGPT，微软：“搜索引擎技术大战，始于今日”
没有 NGINX 和 OpenResty 的未来：Cloudflare 工程师正花费大量时间用 Rust 重构现有功能
访谈文章 | Interview
七年前选择用 Go 和 Rust 做数据库的创业公司，如今怎么评价这个决定？
Log4Shell 一年之后，为什么你还应该信任开源软件安全？
案例研究 | Case Study
从 ClickHouse 到 Apache Doris，腾讯音乐内容库数据平台架构演进实践
经历亿级话单处理优化打磨检验，江苏移动云流一体化到底如何玩转
eBay 为何以及如何转向 OpenTelemetry
推荐文章 | Article
入行 14 年，我还是觉得编程很难
微服务进入深水区后该何去何从
被逼出来的自主可控，从华为自研看国产 IDE 的未来和商业模式
从安全视角看，革命性的 eBPF 是“天使”还是“恶魔”？
谷歌最好的程序员 Jeff Dean：我用过 18 种编程语言
特别专题｜QCon 2022 热门演讲实录
代码快照 x 覆盖率：洞察研发体系的最后 100 米
百万级代码工业软件的云端综合实战
OPPO 全球混合云建设之路
向云原生要数据：日均万亿级数据安全保障和小时级风险应对实践
从 ETL 走向 EtLT 架构，下一代数据集成平台 Apache SeaTunnel 核心设计思路解析
国内首例社区双栈 Istio 方案落地经验，实现代码已开源
特别专栏 | 视频推荐
本月，这些视频值得一看！
评论