实施微服务架构的关键技术.docx

实施微服务架构的关键技术大家都在提微服务架构，微服务架构到底是什么？它有哪些特点和设计模式？我们在打造微服务架构过程中，这些设计模式在实战当中如何应用？数据的一致性应该如何保证？本文将针对上述疑问展开分享。微服务架构特点什么是微服务架构？看下图的这段英文，这是Martin Fowler 在2014年提出来的，微服务架构是一种架构模式，既然是架构模式，那么，它就必然需要满足一些特点。他提到，微服务架构是一系列小的微服务构成的组合，那么，什么是“小的微服务”？可能每个人的理解都不一样，大家都应该都知道SOA架构，SOA架构的粒度是比较粗的，到底我们应该以什么样的粒度拆分微服务？我认为，微服务架构本质上一个业务架构，那么对业务了解的越深刻，你的微服务拆分就越合理。比如我们做二手交易平台（转转），该平台包括用户体系、商品体系、交易体系以及有哪些信誉好的足球投注网站推荐体系。因为各个体系比较独立，那么我们就可以按照各个业务模块来拆分微服务。当然，这样做还不够，因为你的商品里面还有很多功能，但是大的思路是按照具体商品内部的逻辑来进一步拆分。第二，围绕具体业务建模。一切脱离业务场景谈微服务架构都是耍流氓。?方法有二：首先将某一领域的模型作为独立的业务单元：比如二手交易中的商品、订单、用户等；其次将业务的行为作为独立的业务单元：比如发送邮件、单点登录验证、push服务。第三，整个微服务都可以独立地部署，因为每一个维服务Process都是独立的，所以按照每个模块进行独立的部署也是很容易理解的。第四，去中心化管理。打造去中心化管理意思就是微服务的每个模块和开发语言、运行平台没有关系，开发语言可以是C++，可以是go，也可以是世界上最好的语言，运行的平台是Linux，Unix、Windows等都可以。最后一点就是轻量级通信，这点很容易理解，通信和模块语言、平台没有关系。尽可能选用轻量级的通信来做这个事情，这样实施跨平台、跨语言的时候就很容易。讲完这些特点，我们可以看一看一个标准DEMO级的微服务架构到底是由哪些元素组成的？如下图，主要包括网关、微服务、数据存储、注册中心、配置中心。既然是DEMO级的，和实际情况下相比肯定有所差别。那么，实际案例中，我们到底应该如何做这件事情？这个例子也是最近我在做的二手交易平台——转转。这里和DEMO有些不一样的地方。前面的第一层还是网关，下面有微服务的聚合层，作用是做各种业务逻辑的处理；聚合层下面是我们的数据原子层，主要做数据访问代理，只不过根据业务的不同垂直分开了。可以看到，网关、数据层，注册中心、配置中心都有，只不过在业务处理部分分成两层：一层是原子层，也就是整个数据访问的代理层，提供了用户的接口；另外一层就是上层的业务聚合层。架构设计模式及实践案例了解了微服务的一些特点以及DEMO级的微服务包括哪些部分以及实际案例中我们的设架构设计模式。那么，我们为什么要采用这种模式去做？除了这种架构模式之外还有哪些其它的架构模式？这里，模式还是非常多的，我会重点讲这几点：链式设计模式、聚合器设计模式和异步共享模式。首先我们来说下链式设计模式，在这种模式下，APP前端请求首先要经过网关层，接下来连续调用两个微服务，调了微服务1之后还要调微服务2。为什么叫做链式呢？因为在调用过来以后先到微服务1，然后再同步地调用微服务2，微服务2会做一些处理，处理以后微服务2才会反馈给微服务1，微服务1再反馈给Gateway，最后反馈到APP。在实际业务场景中，涉及到交易和订单的业务场景都会用到这种模式。接下来是聚合器设计模式，APP前端一个调用请求经过Gateway，到达聚合层，需要调用三个微服务，聚合层将三个微服务的返回结果做一些聚合处理，比如可以进行一些排序或者去重，聚合之后再反馈到Gateway和APP前端，这是一个典型的聚合器设计模式。第三种模式是数据共享模式，这种模式相对比较简单，比如APP经过微服务网关，接下来调用微服务1和微服务2，理想情况下微服务1和微服务2都有自己独立的DB，但是有些情况下由于微服务1和微服务2的请求量和存储量较小，从资源利用率的角度来讲，这两个微服务的DB是共享的，因此这种就是数据的共享模式。最后一种是异步消息设计模式，不管是链式设计、聚合器模式还是共享数据模式，架构模式都是同步模式。也就是说我的一个请求发出去必须等到每个环节都处理完才会给客户端。如果请求不需要关注处理结果，这时候可以异步来实施。APP更新请求经过微服务网关，持久化到MQ，写入MQ成功后马上Response给APP客户端，之后微服务根据需要从MQ里面订阅更新消息进行异步处理，我们为了提高吞吐量也会采用这种模式。我从百度到转转这几年经历了很多业务场景，使用的无非就是聚合器、异步和数据共享的数据模式，特别是前面两个用得特别多，下面我们来看一些例子。接下来我们看个