16 热度

基于Actor模型的CQRS、ES解决方案分享

跟大家分享的话题是《基于Actor模型的CQRS/ES解决方案分享》,最近一段时间我一直是这个话题的学习者、追随者,这个话题目前生产环境落地的资料少一些,分享的内容中有一些我个人的思考和理解,如果分享的内容有误、有疑问欢迎大家提出,希望通过分享这种沟通方式大家相互促进,共同进步...

收录时间: 2019-07-18
分类: 架构设计
贡献者: Rector
26 热度

扪心自问,你真的熟练掌握MQ了吗?

大家平时也有用到一些消息中间件(MQ),但是对其理解可能仅停留在会使用 API 能实现生产消息、消费消息就完事了。图片来自pexels对 MQ 更加深入的问题,可能很多人没怎么思考过。比如,你跳槽面试时,如果面试官看到你简历上写了熟练掌握消息中间件。那么很可能给你发起如下 4 个面试连环炮:为什么要使用 MQ?使用了 MQ 之后有什么优缺点?怎么保证 MQ 消息不丢失?怎么保证 MQ 的高可用性?本文将通过一些场景,配合着通俗易懂的语言和多张手绘彩图,讨论一下这些问题。为什么要使用 MQ?相信大家也听过这样的一句话:好的架构不是设计出来的,是演进出来的。这句话在引入 MQ 的场景同样适用,使用...

收录时间: 2019-07-15
分类: 架构设计
贡献者: Rector
24 热度

【RabbitMQ】一文带你搞定RabbitMQ死信队列

RabbitMQ是流行的开源消息队列系统,使用erlang语言开发,由于其社区活跃度高,维护更新较快,性能稳定,深得很多企业的欢心(当然,也包括我现在所在公司【手动滑稽】)。 为了保证订单业务的消息数据不丢失,需要使用到RabbitMQ的死信队列机制,当消息消费发生异常时,将消息投入死信队列中。但由于对死信队列的概念及配置不熟悉,导致曾一度陷入百度的汪洋大海,无法自拔,很多文章都看起来可行,但是实际上却并不能帮我解决实际问题。最终,在官网文档中找到了我想要的答案,通过官网文档的学习,才发现对于死信队列存在一些误解,导致配置死信队列之路困难重重。 于是本着记录和分享的精神,将死信队列的概念和配置完整的写下来,以便帮助遇到同样问题的朋友。

收录时间: 2019-07-15
分类: 架构设计
贡献者: Rector
54 热度

基于DDD的微服务设计和开发实战

本文是基于 DDD 的微服务设计和开发实战篇,通过借鉴领域驱动设计思想,指导微服务项目团队进行设计和开发(理论篇详见《当中台遇上 DDD,我们该如何设计微服务?》)。本文包括三部分内容:第一部分讲述领域驱动设计基本知识,包括:分层架构、服务视图、数据视图和领域事件发布和订阅等;第二部分讲述微服务设计方法、过程、模板、代码目录、设计原则等内容;最后部分以一个项目为例讲述基于 DDD 的微服务设计过程。

收录时间: 2019-06-25
分类: 架构设计
贡献者: Rector
47 热度

CQRS+ES项目解析-Diary.CQRS

在《当我们在讨论CQRS时,我们在讨论些神马》中,我们讨论了当使用CQRS的过程中,需要关心的一些问题。其中与CQRS关联最为紧密的模式莫过于Event Sourcing了,CQRS与ES的结合,为我们构造高性能、可扩展系统提供了基本思路。本文将介绍Kanasz Robert在《Introduction to CQRS》中的示例项目Diary.CQRS。获取Diary.CQRS项目该项目为Kanasz Robert为了介绍CQRS模式而写的一个测试项目,原始项目可以通过访问《Introduction to CQRS》来获取,由于项目版本比较旧,没有使用nuget管理程序包等,导致下载以后并不能...

收录时间: 2019-06-24
分类: 架构设计
贡献者: Rector
71 热度

当我们在讨论CQRS时,我们在讨论些神马?

当我们在讨论CQRS时,我们在讨论些神马?当我写下这个标题的时候,我就有些后悔了,题目有点大,不太好控制。但我还是打算尝试一下,通过这篇内容来说清楚CQRS模式,以及和这个模式关联的其它东西。希望我能说得清楚,你能看得明白,如果觉得不错,右下角点个推荐!先从CQRS说起,CQRS的全称是Command Query Responsibility Segregation,翻译成中文叫作命令查询职责分离。从字面上就能看出,这个模式要求开发者按照方法的职责是命令还是查询进行分离,什么是命令?什么是查询?我们来继续往下看。Query & Command什么是命令?什么是查询?命令(Command):不返...

收录时间: 2019-06-17
分类: 架构设计
贡献者: Rector
AD 友情赞助
80 热度

CQRS之旅——旅程4(扩展和增强订单和注册限界上下文)

旅程4:扩展和增强订单和注册限界上下文进一步探索订单和注册的有界上下文。“我明白,如果一个人想看些新鲜的东西,旅行并不是没有意义的。”儒勒·凡尔纳,环游世界80天对限界上下文的更改:前一章详细描述了订单和注册限界上下文。本章描述了在CQRS之旅的第二阶段,团队在这个限界上下文中所做的一些更改。本章的主题包括:改进RegistrationProcessManager类中消息相关的工作方式。这说明了限界上下文中的聚合实例如何以复杂的方式进行交互。实现一个记录定位器,使注册者能够检索她在前一个会话中保存的订单。这说明了如何向写端(Write Side)添加一些额外的逻辑,使您能够在不知道聚合实例惟一...

收录时间: 2019-06-12
分类: 架构设计
贡献者: Rector
90 热度

可用性高达5个9!支付系统高可用架构设计实战

本文重点讨论如何提高应用自身的可用性,关于如何避免单点故障和解决交易量增长问题会在其他系列讨论。 为了提高应用的可用性,首先要做的就是尽可能避免应用出现故障,但要完全做到不出故障是不可能的。互联网是个容易产生“蝴蝶效应”的地方,任何一个看似很小的、发生概率为0的事故都可能出现,然后被无限放大...

收录时间: 2019-06-11
分类: 架构设计
贡献者: Rector
48 热度

架构师成长之路之限流-精讲

在微服务复杂拓扑的情况下,限流是保障服务弹性和拓扑健壮的重中之重。 想一想,如果业务推出了一个秒杀活动,而你没有任何的限流措施;当你搭建了一个账号平台,而完全没有对十几个业务方设定流量配额……这些很有可能在特定场合下给你的产品带来大量的业务损失和口碑影响。

收录时间: 2019-06-10
分类: 架构设计
贡献者: Rector
46 热度

高并发的常用策略

高并发问题可以分为2类:侧重于"读"例如电商的商品详情,商品的查看请求远远高于商品的发布、修改。侧重于"写"例如广告扣费系统,广告主向自己的账号充钱、设置自己的广告,用户浏览或者点击广告后就需要扣费,这个扣费操作的数量是极大的。所以,对于高并发的应对策略也可以从"读"、"写"这2个方面来梳理。一、高并发读策略1:加缓存示例1:本地缓存或集中式缓存缓存可以有效的保护数据库,提高读性能,分为本地缓存,或者集中式的 memcached/redis 缓存。缓存的更新方式有2种:主动更新,数据库记录发生变化时,主动更新缓存数据。被动更新,读缓存时,如果缓存过期,就更新缓存。缓存需要注意的3个问题:缓存雪...

收录时间: 2019-06-10
分类: 架构设计
贡献者: Rector
71 热度

如何保障消息100%成功投递给MQ中间件

我们小伙伴应该都听说够消息中间件MQ,如:RabbitMQ,RocketMQ,Kafka等。引入中间件的好处可以起到抗高并发,削峰,业务解耦的作用。如上图:1、订单服务投递消息给MQ中间件2、物流服务监听MQ中间件消息,从而进行消费如何保障订单服务把消息成功投递给MQ中间件,以RabbitMQ举例。二、分析问题小伙伴们对此会有些疑问,订单服务发起消息服务,返回成功不就成功了吗?如下面的伪代码上面代码中,一般发送消息就是这么写的,小伙伴们觉得有什么问题吗?老顾说一个场景,如果MQ服务器突然宕机了会出现什么情况?是不是...

收录时间: 2019-06-06
分类: 架构设计
贡献者: Rector
77 热度

详解RabbitMQ集群原理,值得收藏

一般来说,如果只是为了学习RabbitMQ或者验证业务工程的正确性那么在本地环境或者测试环境上使用其单实例部署就可以了,但是出于MQ中间件本身的可靠性、并发性、吞吐量和消息堆积能力等问题的考虑,在生产环境上一般都会考虑使用RabbitMQ的集群方案。一. RabbitMQ集群方案的原理RabbitMQ本身是基于Erlang编写,Erlang语言天生具备分布式特性(通过同步Erlang集群各节点的erlang.cookie来实现)。因此,RabbitMQ天然支持集群。集群是保证可靠性的一种方式,同时可以通过水平扩展以达到增加消息吞吐量能力的目的。下图为集群的示例:

收录时间: 2019-06-06
分类: 架构设计
贡献者: Rector
61 热度

全文搜索引擎 ElasticSearch 还是 Solr?

最近项目组安排了一个任务,项目中用到了全文搜索,基于全文搜索 Solr,但是该 Solr 搜索云项目不稳定,经常查询不出来数据,需要手动全量同步,而且是其他团队在维护,依赖性太强,导致 Solr 服务一出问题,我们的项目也基本瘫痪,因为所有的依赖查询都无结果数据了。所以考虑开发一个适配层,如果 Solr 搜索出问题,自动切换到新的搜索--ES

收录时间: 2019-06-04
分类: 架构设计
贡献者: Rector
74 热度

CQRS之旅——旅程1(我们的领域:Contoso会议管理系统)

旅程1:我们的领域:Contoso会议管理系统起点:我们从哪里来,我们带来了什么,谁将与我们同行?“只要前进,我愿意去任何地方。” --大卫•利文斯通本章介绍了一个虚构的公司Contoso。它描述了Contoso计划推出的会议管理系统,这是一个新的在线服务,可以使其他公司或个人通过此系统组织和管理自己的会议和活动。本章从高层次描述了新系统的一些功能和非功能需求,以及为什么Contoso希望使用CQ...

收录时间: 2019-05-29
分类: 架构设计
贡献者: Rector
79 热度

苏宁如何解决事务与非事务的数据一致性问题

作为拥有线上线下大数据的智慧零售平台,苏宁的系统对于并发和高效要求非常高。针对各种苛刻的场景,苏宁都有相应的解决方案。苏宁的售后订单系统每天要处理大量订单的创建,修改以及数据分发的操作。为了保证高效,我们的数据经过分库分表存储于数据库集群中,同时根据一定的算法将部分活跃订单缓存在Redis,保证订单处理的效率。

收录时间: 2019-05-27
分类: 架构设计
贡献者: Rector
AD 友情赞助
84 热度

什么是架构设计的五个核心要素?

架构中五个重要的核心指标:分别是性能、可用性、伸缩性、扩展性和安全性。一、性能性能就是核心要素之一,不然我为什么架构设计?随随便便一个lowlow的系统上线就好了。所以性能优化是很多小公司卖不去过的坎。这么说吧,当然优化网站性能的手段也非常多:(1)web前端性能优化:浏览器访问优化(浏览器缓存、页面压缩传输、合理布局页面、减少Cookie传输)减少http请求。避免建立太多通讯链...

收录时间: 2019-05-22
分类: 架构设计
贡献者: Rector
69 热度

OAuth2.0认证流程是如何实现的?

大家也许都有过这样的体验,我们登录一些不是特别常用的软件或网站的时候可以使用QQ、微信或者微博等账号进行授权登陆。例如我们登陆豆瓣网的时候,如果不想单独注册豆瓣网账号的话,就可以选择用微博或者微信账号进行授权登录。这样的场景还有很多,例如登录微博、头条等网站,也都可以选择QQ或者微信登录的方式。那么这样的第三方登陆方式到底是怎么实现的呢?难道是腾讯把我们QQ或者微信的账户信息卖给...

收录时间: 2019-05-06
分类: 架构设计
贡献者: Rector
127 热度

Apollo 1.4 发布,携程开源的分布式配置中心

Apollo(阿波罗)是携程框架部门研发的分布式配置中心,能够集中化管理应用不同环境、不同集群的配置,配置修改后能够实时推送到应用端,并且具备规范的权限、流程治理等特性,适用于微服务配置管理场景。 服务端基于Spring Boot和Spring Cloud开发,打包后可以直接运行,不需要额外安装Tomcat等应用容器。Java客户端不依赖任何框架,能够运行于所有Java运行时环境,同时对Spring/Spring Boot环境也有额外支持。.Net客户端不依赖任何框架,能够运行于所有.Net运行时环境。

收录时间: 2019-05-05
分类: 架构设计
贡献者: Rector
91 热度

CQRS and exception handling - Enterprise Craftsmanship

This is the last article in the series of articles designed to supplement my CQRS in Practice course. In it, I’d like to discuss one particular aspect of exception handling relevant to CQRS and the decorator pattern.

收录时间: 2019-04-18
分类: 架构设计
贡献者: Rector
111 热度

使用MediatR重构单体应用中的事件发布/订阅

使用MediatR重构单体应用中的事件发布/订阅,在之前的一篇文章中,我分享了一个在ASP.NET Core单体程序中,使用事件发布/订阅解耦业务逻辑的例子。

收录时间: 2019-04-02
分类: 架构设计
贡献者: Rector
AD 友情赞助