卷首语

从微服务过去十年发展中，我们能学到什么？

作者：Tina

根据Wiki的说法，在2011年的时候，一群聚会中的架构师不知道如何命名自己正在探索的架构风格，于是他们使用了“微服务”这个词。这种架构风格，在得到正式命名之前也被一些人称为细粒度SOA，即面向服务的架构，当时还存在着一些来自早期尝试者的负面反馈。但是没想到仅一年的时间，“微服务”这个词就开始因为技术演讲而流行了起来，变成了一个正式的名称。

这些早期实践者在宣传技术理念时，表示它可以使组织“走得更快”，从而快速交付业务价值，业界也开始达成一致，普遍认为它“显着提高了开发效率，使我们能够大胆思考并进行实质性的产品改进，并让工程团队能够安全地测试新技术。”

微服务就这么火了起来，迅速跨越“早期采用者鸿沟”成为了主流架构，一些早期参与者甚至觉得自己“创造了未来”。到了2018年左右的时候，InfoQ还发布了“微服务成熟度状况”调查报告，报告显示接受调查的从业者对微服务总体持有非常积极的态度，似乎微服务已经成为了架构领域的“银弹”。

实际上，Fred George，也有人称他为“微服务之父”（其研究和宣传都早于Martin Fowler），在2016年就提出单靠微服务的实施不会给组织带来成功，必须识别和解决技术、流程和组织环境中阻碍业务敏捷性提高的因素。2020年，他还以“Why I Wouldn't Use MicroServices”为题发表了一次演讲，强调不同的问题需要不同的解决方案，但他发出的声音没有足够引起大家重视。

当采用微服务的组织增多，微服务本身也越来越复杂，大家在实践中踩的“坑”也就多了起来。虽然一直有人总结经验教训，但阻止不了微服务的全面采用。直到GitHub前CTO喊出了那句震惊业界的话：“全面微服务是最大的架构错误！”回头去看，过去的这些经验告诉我们，如果你的组织交付软件的速度太慢，那么采用微服务可能不会解决这个问题，而且还有可能会使情况变得更糟。因为一开始人们认为微服务与服务规模有关，但它更多是要解决开发人员基数太大、代码的开发和发布周期太长的问题。

我们受益于微服务带来的很多好处，也需要承担架构复杂性带来的成本，这中间存在着取舍。但就像前Netflix云系统总监Adrian Cockcroft所说的那样，架构可以复杂，也可以没那么复杂。可用的简单架构很多，选择适合自己的才最重要。这一切在于选择的人，因此不能全算是微服务的锅。