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

18-10-08 banq
                   

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

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修改过]

                   

2