Tagged: 微服务

0

常见的微服务boundary划分考虑因素

我们在前文中介绍了DDD在微服务boundary划分中的指导意义,但显然它并不是唯一的划分准则,本文就来介绍几个其它在微服务划分的时候经常需要的考虑因素,我们通常会把它们和DDD集合起来做最终的决定。 波动性(Volatility) 这个世界变化很快,我们有时需要提前考虑系统某一个部分是否会频繁修改,以及是否需要把相应的功能抽象出来成为服务,从而使他们的执行更有效。 一个简单的例子,早期的购物网站可能不支持线上支付,那么在支付页面只需要留一个订购电话,用户只能拨打电话进行订购。这个时候的支付功能是否需要独立一个service来处理呢?也许不一定。而随着时间的推移,支付的方式不断进行演进,比如开始支持信用卡的支付,支持微信支付宝的支付,这个时候把支付独立出来成为一个新的微服务是否更加合理?假设后来每种支付方式开始出现不同的后续操作,比如微信支付之后有了微信购物抢红包的功能,或者使用支付宝支付有了其特有的couple和额外操作等等,是否需要把微信,支付宝都进行独立微服务处理呢?这些都是需要考虑的,总得来说,考虑服务的波动性也就是改变频率是一个不错的建议。 数据...

0

Domain-Driven Design在微服务中的使用

一般来说在我们在讨论如何设置微服务的boundaries的时候,会围绕domain来进行考虑。因此Domain-Driven Design(DDD)在这个过程中就可以提供很不错的帮助,本文就来聊聊我们在微服务中是如何使用DDD的。DDD其实包含了很多内容,我们这里主要关注两个重要的思想:聚合(Aggregate)以及界限上下文(Bounded context)。 聚合(Aggregate) DDD中的聚合有时候也让人confuse,不是很明确究竟是什么意思。一个比较简单的理解就是我们可以认为它是一个真实domain概念的展现,就是说它通常有一个生命周期,我们可以通过一个状态机来实现它。...

0

微服务基础介绍之耦合

我们在之前的文章中对微服务进行了概述,相信大家对微服务也有了一定的了解。有很多人会问,我们该怎么来把一个系统拆分成多个微服务呢?要想回答这个问题,就需要知道各个微服务之间都有哪些类型的耦合,本文就来和大家聊一聊微服务的耦合类型。 Domain Coupling 所谓Domain的coupling其实很简单,就是一个微服务和另外一个微服务之间耦合的原因就是因为一个微服务需要使用另外一个微服务的功能。 我们来看一个简单的例子,我们下单购买某一个物品,这里涉及几个模块,一个是Order...

0

微服务概述

我们都知道微服务现在越来越流行,关于微服务有很多内容可以讨论,笔者最近也阅读了很多相关资料,准备开始一个关于微服务的系列文章,今天就先来和大家来聊一聊什么是微服务。 概述 所谓微服务简单来说就是围绕一个business domain来实现的可以独立release的各种服务。每个服务都有各自的功能,并且能够被别的服务通过网络来进行访问,从而构建一个整体完整的功能。就像我们在淘宝购物,一个服务显示当前的库存,一个服务管理相应的订单,一个服务管理订单的发货,然后他们整合在一起构成了我们一个购物的系统(只是随便说了几个服务,显然现实中的淘宝要比这个复杂得多)。 从另外一个角度来说,我们也可以认为微服务是一个面向服务的架构。每一个“微服务”本身我们可以认为是一个黑盒,它实现了某些特定的功能,外面对它是如何实现的并不需要关心,只关心它的网络接口(REST...

0

事件驱动架构的优势

每天产生的数据正在呈现指数级的增长,不管这些数据是由各种传感器产生还是有用户点击网络产生,亦或是系统内容交互的数据,我们的应用需要处理和这些数据相关的事件将会越来越多。那么怎样设计一个很好的架构来处理这些事件呢? 本文,我们将会讨论什么是事件驱动的架构(EDA)以及这个架构是这样把事件放到系统的核心地位的。然后我们再聊聊这样的架构都有哪些优势。 什么是事件 所谓的事件,就是记录已经发生的事情,或者一个状态的改变。他们是不可改变的,并且是按照发生的顺序排列的。对这些事件感兴趣的部分可以注册这个事件,然后再根据这些事件来做相应的商业逻辑。 什么是事件驱动的架构...