14 热度

缓存穿透、缓存击穿和缓存雪崩实践

我们使用缓存的主要目是提升查询速度和保护数据库等稀缺资源不被占满。而缓存最常见的问题是缓存穿透、击穿和雪崩,在高并发下这三种情况都会有大量请求落到数据库,导致数据库资源占满,引起数据库故障。

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

DDD and bulk operations

Combining bulk operations with Domain-Driven Design is a tough problem. In this article, we’ll look at why that is so and discuss ways to marry the two.This article is also a response to a reader question. The question contained an interesting example, which I’ll use throughout this post:

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

NServiceBus+Saga开发分布式应用

当你在处理异步消息时,每个单独的消息处理程序都是一个单独的handler,每个handler之间互不影响。这时如果一个消息依赖另一个消息的状态呢? 这时业务逻辑怎么处理?借用我们上篇文章的业务场景,如果在Ship项目里需要发送一个ShipOrder Command。这个ShipOrder需要依赖Sales.OrderPlaced和Bill.OrderBilled Command的状态,目前我们的两个单独的Message Handler都没有保持任何的状态字段,所以这时如果我们需要完成这个业务模型,就需要跟踪他们的状态。什么是Saga这个就是本篇文章要提的saga,定义在NServiceBu...

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

Avoiding the Repository Pattern with an ORM

For many years now I’ve advocated not using the repository pattern on top of an ORM such as Entity Framework. There are many reasons why that I’ll try and cover throughout this post based on ways that I’ve seen it implemented. Meaning, this post is talking about poorly implemented approaches or pi...

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

同时支持EF+Dapper的混合仓储,助你快速搭建数据访问层

17年开始,公司开始向DotNet Core转型,面对ORM工具的选型,当时围绕Dapper和EF发生了激烈的讨论。项目团队更加关注快速交付,他们主张使用EF这种能快速开发的ORM工具;而在线业务团队对性能有更高的要求,他们更希望使用能直接执行Sql语句的Dapper,这样可控性更高。而对于架构团队来说,满足开发团队的各种需求,提高他们的开发效率是最核心的价值所在,所以当时决定做一个混合型的既支持EF又支持dapper的数据仓储。为什么选择EF+Dapper目前来说EF和Dapper是.NET平台最主流的ORM工具,团队成员的接受程度很高,相关的资料非常齐全,学习成本很低,各种坑也最少...

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

Tips, tricks, and good practices for Data-Driven Testing. Part 2.

This article is Part 4 in a 4-Part Series.This post is a continuation of a previous tips, tricks, and good practices for Data-Driven Testing entry. This one with more code.

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

[NewLife.XCode]分表分库(百亿级大数据存储)

NewLife.XCode是一个有15年历史的开源数据中间件,支持netcore/net45/net40,由新生命团队(2002~2019)开发完成并维护至今,以下简称XCode。整个系列教程会大量结合示例代码和运行日志来进行深入分析,蕴含多年开发经验于其中,代表作有百亿级大数据实时计算项目。开源地址:https://github.com/NewLifeX/X...

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

Refactoring to Data Driven Tests

I am not a big fan of writing tests. I like having them, but I find writing them to be boring. That said, retesting manually is even more annoying, so I write tests. The thought that there has to be a better way, never passed. I tried a few approaches. After some experimentation, I think I have the answer - DDT (Data Driven Testing)

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

Four Better Rules for Software Design

Martin Fowler recently tweeted a link to his blog postabout Kent Beck’s four rules of simple design,which I think could be improved upon (and, which can lead programmers down the wrong path at times):Kent’s rules, from Extreme Programming Explainedare:Runs all the testsHas no duplicated logic. Be wa...

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

Best Practices for Designing Akka.NET Domain Events and Commands

In this blog post we’re going to cover some best practices you can use when designing domain events and objects intended to work with Akka.NET. If you follow these best practices you’ll run into fewer errors, clearer log messages, and a better extensibility experience.

收录时间: 2019-08-02
分类: 架构设计
贡献者: Rector
103 热度

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

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

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

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

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

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

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

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

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

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

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

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

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
AD 友情赞助
182 热度

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

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

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

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

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

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

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

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

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

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

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

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

高并发的常用策略

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

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