背景： 现在后端使用微服务方式开发，然而分布式系统带来了很多问题，比如： 现在公司开发了一个RPC框架来给各组开发人员使用，为了支持高并发，OrderService部署了4份，也就意味着每个客户端保存了一份服务提供者的列表，但是这个列表在配置文件中是写死的，意味着如果某台服务器down了，客户端并不知道，依然会尝试访问。 客户端与服务提供者紧耦合，要解决这个问题，要加一个中间层。 理解RP

在最近的一次Microservices Practitioner Summit中，原Netflix工程师介绍了一种越来越常见的对Microservice的误用。简单地说，大家在搭建一个基于Microservice的服务时常常依赖同一套类库，进而使得Microservice中的各个子服务无法选择最适合的技术。 　　如果您不知道Microservice是什么，请首先阅读我的另一篇文章《Mi

1. 引言 Ordering microservice（订单微服务）就是处理订单的了，它与前面讲到的几个微服务相比要复杂的多。主要涉及以下业务逻辑： 订单的创建、取消、支付、发货库存的扣减 2. 架构模式 如上图所示，该服务基于CQRS 和DDD来实现。 从项目结构来看，主要包括7个项目： Ordering.API：应用层Ordering.Domain：领域层Ordering.Infrast

看了这篇文章总体上会对微服务有个认识，如果不是分布式应用和采用云部署模式，微服务基本上是一个技术概念，如果不能得以实践，姑且听之。 首先来了解一些概念，以下内容来自：http://www.jdon.com/soa/microservice-architecture.html 什么是微服务架构? 　　微服务是指开发一个单个 小型的但有业务功能的服务，每个服务都有自己的处理和轻量通讯机制，可以