单体架构与微服务的反思
内容提要
亚马逊最近优化了监控服务，采用单一服务替代微服务，引发了关于微服务的争论。尽管微服务存在复杂性和成本问题，但它们仍能提升技术交付与业务目标的对齐。架构选择应基于对业务价值的理解，而非盲目追随潮流。理想情况下，架构应结合单体和微服务，以满足实际需求。
延伸解读
亚马逊案例的启示
亚马逊将监控服务从微服务重构为单一服务，是基于对流量和成本的深入理解进行的优化，并非否定微服务或Serverless。这提醒我们，架构应随问题域认知的演进而调整，而非固守某种模式。对于长时运行或高可预测负载，用更大组件优化Serverless应用是合理选择。
微服务的初衷与现实
微服务最初旨在赋予实现团队更多自主权，避免集中式编排和自上而下的决策。然而，由于大规模部署小服务的复杂性，许多微服务架构反而将交付团队与基于Kubernetes的集中式内部开发者平台耦合。这导致灵活性和可扩展性的承诺常演变为失控的复杂性和高昂成本。
架构选择应基于业务价值
架构决策应由对业务目标和架构如何增加价值的清晰理解驱动，而非盲目追随潮流。在采用微服务前，需解决部署自动化、环境配置、追踪和监控等问题，并建立服务协作的治理规则。同时，团队能力至关重要：若系统代码难以变更，微服务不会神奇地转变工程文化，反而可能分散坏代码并增加坏基础设施。
避免过早分解与错误二分法
许多微服务架构因过早分解而受损，将微小单一职责服务作为起点而非优化，导致难以管理的“分布式泥球”。理想情况下，服务应对齐领域驱动设计中的“限界上下文”，实现松耦合与高内聚。微服务与单体并非二元对立，架构可混合容器化服务、Serverless函数甚至单体应用。通常最好从模块化单体开始，根据真实需求逐步分解。
Q&A
亚马逊为什么选择用单一服务替代微服务？
亚马逊通过单一服务优化监控服务，以更好地管理规模和成本，反映了对架构的逐步优化。
微服务架构有哪些潜在的复杂性和成本问题？
微服务架构可能导致交付团队与复杂的内部开发平台相结合，增加管理难度和成本。
在选择架构时应该考虑哪些因素？
选择架构时应考虑业务价值、部署自动化、环境配置、监控等问题。
微服务是否总是比单体架构更优？
并非如此，微服务可能导致复杂性增加，单体架构在某些情况下更易于管理。
如何避免微服务架构中的功能重复和服务膨胀？
需要严格管理服务边界和依赖关系，确保服务设计符合领域驱动设计的原则。
微服务架构的最佳实践是什么？
最佳实践是从单体架构开始，依据实际需求进行分解，避免过早分解导致的复杂性。
