Architecture 软件架构师能否预测微服务架构将如何随着时间的推移而成熟？

2014年3月，詹姆斯·刘易斯（James Lewis）和马丁·福勒（Martin Fowler）写道（就在四年前，在提出这个问题的时候）：

许多人认为，微服务不太可能出现[模块化随时间的衰减]，因为服务边界是明确的，很难修补。然而，直到我们看到足够多的系统具有足够的年龄，我们才能真正评估微服务架构是如何成熟的

---

现在，许多MSA都是由各种各样的企业构建的，我们对这些体系结构的成熟度有一个大致的了解吗？随着时间的推移，我们知道什么是有效的？我们知道什么不起作用？

您的问题的答案是非常主观的，取决于在整个解决方案/系统中预先投入了多少架构和设计工作，以及围绕集成、部署等对系统进行架构更改时有多少治理控制

但从经验来看，我可以（几乎）绝对保证体系结构会随着时间的推移而演变，不同的解决方案会出现在不可预见和/或计划外的功能和技术需求中。面对敏捷的、不断变化的需求，任何体系结构都不会完好无损

另一个需要考虑的因素是，工具、模式和技术在我们的行业中变化非常快。因此，一个项目完成的时间越长，它就越容易受到这些领域变化的影响。这是另一个事实（在我看来）

然而，不变的是这些架构决策背后的动机。为什么？ 体系结构治理需要捕获这些动机，并确保它们通过长期使用的任何不断发展的工具、模式或技术得到满足

---

对于我自己的项目，我确保我们做出的任何架构决策的一个重要因素都是由业务驱动因素与开发人员经验（DX）的平衡观点驱动的，以确保清晰性、生产力、掌握性、稳定性、质量等。

这个问题是在征求意见，当我们刚刚开始了解MSA时，FAAS从后面迅速发展起来。实际上，架构背后有很多因素需要根据业务需求或消费者行为进行演变。以Netflix为例，由于业务需求，他们转向微服务，然后为了改善消费者行为，他们还采用了反应式系统。所以对于架构师来说，这都是一些特殊的需求，这使得他们不断思考如何使架构成熟。正如人们所说的：“今天的需求根本不能被昨天的软件架构所满足”我理解在评估架构时涉及到主观性。我所追求的是在时间流逝后，建筑师对项目的信念的确认/失效。在2014年选择MSA时，可能是架构师认为模块化随着时间的推移而衰退的可能性较小：客观地说，2014年实施系统的架构师是否认为到2018年模块化实际上已经衰退？是的，我理解存在强烈的解释偏见。但是想想Lewis和Fowler的问题：“很多人相信……”。你可以将我的问题改为：“四年过去了，架构师多久验证一次他们对MSA的信念？”我明白了。我认为这里没有单一的答案。架构在变化的环境和决策下会有不同的发展。目前还没有确定模式。