malaoko

这个系列我们大概写了八篇文章，将微服务的最重要的内容过了一遍。当然其中有些内容还没有涉及到，比如Docker（不是微服务架构风格中必须的）等，关于Docker我们自己可以在网上找找其他文章。 这篇文章就来回顾下微服务架构风格是如何落地的，如果你对以下回顾的内容都很清楚并已经有一…

在微服务架构风格的系统中，如果单个微服务垮掉或地址不可访问，虽然对系统的影响是有限的，但我们也必须采取一定的手段来保证每个微服务尽量可用；并且在大并发的情况下，虽然可以通过EDA消息队列处理的方式提高吞吐量，但仍然需要WebApi能够更加高效的侦听用户请求，处理消息，即使在某个…

我们先来看看CQRS架构，你对下图的架构还有印象吗？每个组件的功能都还清楚吗？如果有疑问，请查考文章《微服务实战(五)：落地微服务架构到直销系统(构建高性能大并发系统)》。 1.前端用户调用一个下单Command WebApi，传递下单命令；下单Command WebApi接受…

在CQRS架构中，一个比较重要的内容就是当命令处理器从命令队列中接收到相关的命令数据后，通过调用领域对象逻辑，然后将当前事件的对象数据持久化到事件存储中。主要的用途是能够快速持久化对象此次的状态，另外也可以通过未来最终一致性的需求，通过事件数据将对象还原到一个特定的状态，这个状…

在现代系统中，特别是互联网软件，通常会涉及到大量用户的并发访问，我们的系统一定要在架构上支持高性能、大并发的访问。一个高性能的系统通常由很多的方面组成，包括数据库高性能、Web服务器高性能、负载均衡、缓存、软件架构等。我们这篇文章先从软件开发架构的角度作为切入点来介绍如何构建高…

前一篇文章我们已经完成了基于RabbitMq实现的的消息总线，这篇文章就来看看生产者(订单微服务)与消费者(经销商微服务)如何接入消息总线实现消息的发送与消息的接收处理。 下单消息要被发送到消息总线，并被经销商微服务的处理器处理。经销商微服务处理时，需要知道要对哪个经销商处理多…

从前面文章可以看出，消息总线是EDA(事件驱动架构)与微服务架构的核心部件，没有消息总线，就无法很好的实现微服务之间的解耦与通讯。通常我们可以利用现有成熟的消息代理产品或云平台提供的消息服务来构建自己的消息总线；也可以自己完全写一个消息代理产品，然后基于它构建自己的消息总线。通…

从上一篇文章大家可以看出，实现一个自己的消息总线框架是非常重要的内容，消息总线可以将界限上下文之间进行解耦，也可以为大并发访问提供必要的支持。 1.界限上下文解耦：在DDD第一波文章中，当更新了订单信息后，我们通过调用经销商界限上下文的领域模型和仓储，进行了经销商信息的更新，这…

网上有很多关于微服务的文章，从不同的维度对微服务进行了相关的讲述；有些高屋建瓴，有些涉及细节，有些侧重理论，有些侧重代码，都是非常不错的了解微服务的文章。 我们这个系列的文章的维度主要是实战落地，也就是我们在平常工作以及产品开发过程中，考虑为什么选择微服务架构风格，以及如何将微…