精心设计的单体架构也是好的

该文认为单体巨石架构如果经过良好设计也是很好的，但是什么是良好设计呢？原文：

DevOps Days London今年很棒！会谈很有意思，文化包容性和友好性。

我一直认为我们应该建立'正确的服务'，而不是为了用'微服务'而用'微服务'。使用微服务相当于还要使用Kubernetes和一个docker容器 - 你会有更多的etcd节点......

在这篇博文中，我想分享DevOps天开放空间讨论的一个结果，讨论什么是/为什么好的巨石单体架构，为什么它可以作为起步开始。

那么为什么经过良好设计和开发的巨石系统也是很好的？

1. 快速失败 - 他们让开发团队专注于提供功能（证明或反驳假设），而不是复杂的微服务架构
2. 它可以帮助您了解您的需求（第一次实现UML图和领域模型时并不完美）
3. 微服务的开发很复杂（例如，优雅降级，健康检查，重试）和监控
4. 微服务依赖性很难跟踪

那么好的巨石看起来像什么：

1. 代码库由组件模块化（例如发票，项目）
2. 组件之间的异步通信应使用队列（例如RabbitMQ）。某个代码库只是发布和使用消息
3. 在一个单独的进程中如果使用队列最好了（例如RabbitMQ docker容器）

一旦应用被证明，那么如果需要，可以开始分解了：

1. 支持水平缩放
2. 降低部署风险
3. 将应用程序组件的开发分发给其他小队
4. 简化调试和维护

参与讨论后的结论是：在糟糕的巨石单体在分解为微服务之前，将这个巨石单体设计为良好架构是重要的步骤，这是因为无论巨石多么糟糕，它已经过实战测试了。

banq评：在需求开始之初，需要快速迭代，摸清需求，发现需求中逻辑，摸清实体与值对象，以及它们所处的上下文，及其在这个上下文中的存在意义，使用SpringBoot进行快速原型开发是一条好的方式，虽然SpringBoot是微服务框架，但是项目开始之初，用它来做一个小型的单体系统，然后让前端配合界面设计，最终让用户使用起来。

总得来说：我们需要一种方法和技术来摸清需求，快速拿出原型。DDD+Spring Boot无疑是这套快速敏捷的组合。

Well Architected Monoliths is good

[该贴被banq于2018-10-08 10:29修改过]