未来的软件开发将越来越分布式——这是肯定的。但分布式并不一定意味着微服务。真正的艺术在于找到适当的平衡：灵活性与控制之间、自主性与治理之间、创新与稳定之间的平衡。
也许最重要的建议是：不要因为“每个人都在做”或者因为它听起来很现代而从微服务开始。从微服务开始，因为您了解该架构可以解决的具体挑战。为旅程做好准备 — — 迎接旅途中遇到的所有起起伏伏。
微服务不是一种目标状态，而是一个持续的演进过程。这一演变需要卓越的技术、敏捷的组织和成熟度的文化。如果您愿意踏上这段旅程，并有耐心、毅力和学习意愿，那么微服务可以成为您组织深刻积极变革的催化剂。
未来不一定属于微服务——它属于那些了解如何协调架构、人员和流程以创造真正商业价值的组织。有时最好的第一步是认识到您可能还没有为微服务做好准备 - 这是完全没问题的。
令人惊讶的是，我经常听到这个问题，这表明人们普遍存在误解。将巨石标记为“过时”就像说地基坚固的房屋已经过时一样。结构良好的整体式结构可以成为许多应用的理想解决方案。
让我给你举一个实际的例子：一家中型公司多年来一直成功 乌干达 WhatsApp 数据 地以模块化整体方式运营其电子商务平台。该系统易于管理，开发人员知识渊博，部署简单，性能良好。他们为什么要改变行之有效的方法？
关键问题不是“整体还是微服务？”，而是“什么适合我们的特定要求？”。如果设计精良且满足您的要求，那么整体式架构可以是最先进的且面向未来的。
“我如何知道我的项目是否已为微服务做好准备？”
这个问题让我想起了与一位热衷于转向微服务的 IT 经理的对话——“因为 Netflix 也这样做”。但这有点像买一辆一级方程式赛车只是为了从面包店买面包。
微服务的成熟度并不太体现在公司或应用程序的规模上，而是体现在某些关键指标上：
首先，你们的 DevOps 文化是什么样的？仍然在手动部署方面苦苦挣扎的团队不会对微服务感到满意。
第二，你能否承受可能的一致性？我记得有一家金融机构想要使用微服务，但需要绝对的实时一致性。它们就是不合适。
第三，你们的团队到底有多自主？如果每个决策都要经过三个委员会，那么微服务承诺的敏捷性就永远不会成为现实。
“分布式整体式架构可以转变为真正的微服务吗？”
“你能把一堆意大利面条变回一根一根的直面条吗？” ——这是开发人员对这个问题的讽刺性回答。但与意大利面条不同的是，转变分布式整体实际上是可能的 - 尽管具有挑战性。
我曾经陪同过一个团队，他们面临着同样的任务。多年来，他们的系统已经成为一个相互依赖的网络。你的方法？他们首先对服务之间的通信进行了可视化。最终绘制的图表在墙上挂了好几个月——既是纪念品，也是路线图。
转型是通过逐步的方式实现的：首先，他们确定了最紧密耦合的服务并开始将其拆分。他们引入了事件源，而之前都是直接调用。他们在以前共享的数据库中复制了数据。虽然道路漫长，但是他成功了。
最重要的建议是：不要将这种转变视为一个纯技术项目。技术变革往往是比较容易的部分。更大的挑战在于改变思维方式、流程和组织结构。分布式整体通常是更深层次组织模式的征兆——这些模式也必须改变。