架构运维

上集我们阐述了使用微服务体系架构的关键障碍是领域模型,事务和查询,这三个障碍似乎和功能拆分具有天然的对抗。只要功能拆分了,就涉及这三个难题。 然后我们向你展示了一种解决方案就是将每个服务的业务逻辑实现为一组DDD聚合。然后每个事务只能更新或创建一个单独的聚合。然后通过事件来维护聚合(和服务)之间的数据一致性。 在本集中,我们将会向你介绍使用事件的时候遇到了一个新的问题,就是怎么样通过原子方式更新聚合和发布事件。然后会展示如何使用事件源来解决这个问题,事件源是一种以事件为中心的业务逻辑设计和持久化的方法。之后,我们会阐述微服务架构下的查询困难的问题。然后向你介绍一种称为命令查询责任分离(CQRS)的方法来实现可扩展和高性能的查询。 可靠地更新状态和发布事件从表面上看,使用事件来保持聚合之间的一致性似乎很简单。 当一个服务创建或更新数据库的一个聚合时,它只是简单地发布一个事件。但是,这只...

微服务架构变得越来越流行了。它是模块化的一种方法。它把一整块应用拆分成一个个服务。它让团队在开发大型复杂的应用时更快地交付出高质量的软件。团队成员们可以轻松地接受到新技术,因为他们可以使用最新且推荐的技术栈来实现各自的服务。微服务架构也通过让每个服务都被部署在最佳状态的硬件上而改善了应用的扩展性。 但微服务不是万能的。特别是在 领域模型、事务以及查询这几个地方,似乎总是不能适应拆分。或者说这几块也是微服务需要专门处理的地方,相对于过去的单体架构。 在这篇文章中,我会描述一种开发微服务的方法,这个方法可以解决这些问题。主要是通过领域模型设计,也就是DDD以及事件源(Event Sourcing)以及CQRS。让我们首先来看看开发人员在开发微服务的时候会遇到哪些问题吧。 微服务开发过程中的挑战模块化在开发大型复杂的应用的时候是非常有必要的。 现在许多应用大到一个人根本无法完成。而且复杂到...

今天重读了Martin Fowler的《Microservices》,在此记录一下对九大特性的理解。 服务组件化组件,是一个可以独立更换和升级的单元。就像PC中的CPU、内存、显卡、硬盘一样,独立且可以更换升级而不影响其他单元。 在“微服务”架构中,需要我们对服务进行组件化分解。服务,是一种进程外的组件,它通过http等通信协议进行协作,而不是传统组件以嵌入的方式协同工作。服务都独立开发、部署,可以有效的避免一个服务的修改引起整个系统的重新部署。 打一个不恰当的比喻,如果我们的PC组件以服务的方式构建,我们只维护主板和一些必要外设之后,计算能力通过一组外部服务实现,我们只需要告诉PC我们从哪个地址来获得计算能力,通过服务定义的计算接口来实现我们使用过程中的计算需求,从而实现CPU组件的服务化。这样我们原本复杂的PC服务得到了更轻量化的实现,我们甚至只需要更换服务地址就能升级我们PC的...