（转）微服务框架落地实践之路

http://www.primeton.com/read.php?id=2276&his=1

1、微服务架构产生的背景

 

近十年中，互联网给咱们生活带来了翻天覆地的变化，消费者的生活方式日益数字化，人们能够在任什么时候间、任何地点利用网络进行购物体验，运用社交媒体进行自我表达，企业也在运用多种技术手段，发挥数字化潜力，改善客户联系，促进企业业务模式的转型。在这种背景下，互联网也好，传统企业也罢，都面临一个共同的需求：面对快速变化的需求，面对业务模式的升级，如何构建出灵活的，可扩展，可重用的系统？

 

前几年咱们经常使用的三层应用架构，常常会将系统落地成单块应用，全部的功能都运行在一个进程中，各个模块之间的功能是强依赖的，修改一个模块的功能很容易致使其余模块出现问题，并且一旦须要将系统发布必须作一次全量发布，发布周期长。若是团队中加入新人，对系统的学习成本也很高，须要了解完整个系统才能进行开发。在这种状况下，如何将系统进行拆分，使得各个模块独立衍化成为关键。

 

近几年随着容器技术的发展，其中以docker容器技术为表明，一时间席卷了整个IT行业，受到大量开发者和企业热烈追棒。docker容器技术以一种轻量级的方式能够很是方便的将应用及其依赖打包到一块儿，而后能够发布到任意装有docker的Linux机器上面。docker的出现，有效的解决了大量服务因数量众多而致使的开发环境搭建、部署复杂及运维成本高的难题。

 

在这种背景下，若是说随着敏捷、精益方法论深刻人心，持续交付以及Devops逐渐火热促进了微服务架构出现，那么Docker容器技术的出现，解决了部署，运维困难的问题后，则直接为微服务架构的大规模应用起到了推波助澜的关键做用。

 

虽然微服务架构能让每一个单一的服务进行独立的衍化，能得到诸多好处，可是微服务并非银弹，实施微服务架构同时也会带来其余问题，如集成复杂，运维困难，服务间依赖测试，服务间依赖管理等一系列新问题。如在在微服务架构中，每一个服务间彼此独立，一个服务可能须要依赖另外一个服务，而此时另外一个服务也正处在开发中，则没法进行依赖，此时就须要对服务进行mock，方便服务间依赖测试；又好比在运行期，某个微服务A运行较慢，则全部依赖服务A的其余服务都会受到影响等等；像这样的问题，在微服务架构中还有不少，这里不一一举例。

 

2、微服务框架落地的7个关键点

 

 

在微服务架构中，针对微服务架构须要解决的一系列问题，咱们将一些基本的问题进行抽象，统一解决，独立出一套基础的框架，方便快速实施微服务架构，如下是咱们微服务框架的一些基本能力：

 

在上图中，咱们将微服务框架的基本能力分为2部分，第一部分是基础能力，这部分能力并非微服务特有的，是不少系统都须要的一些基础能力，这里主要是日志，异常，文档等；第二部分是微服务框架的核心能力，主要解决微服务架构中的一些基本问题：如负载均衡、RPC、服务注册与发现等。在微服务框架基础之上，就是业务逻辑，即真正对外提供的业务服务，目前全部的业务逻辑对外暴露的服务统一都是restful服务。下面咱们主要讲述微服务框架落地的7个关键点，供你们在落地微服务架构的时候进行参考：

 

RPC：服务通信的基础。不管是SOA仍是微服务，核心都是RPC框架。若是没有统一的RPC框架，各个团队就须要实现本身的一套序列化、反序列化、网络框架、链接池，线程池、超时处理等“业务以外”的重复劳动，因此统一RPC框架，是服务化首先要解决的问题。现阶段，外界RPC框架众多，若是没有特殊需求，并不须要自研一套。

 

目前可选的RPC框架有：dubbo/dubbox，motan，thrift，grpc，Karyon/Ribbon, 在RPC框架的选择上，咱们选择了比较轻量级的motan开源框架，理由是“麻雀虽小，五脏俱全“，足够轻量级，却解决了RPC须要解决的大部分问题，如负载均衡、容错、服务注册与发现、限流、降级等。

 

motan相比于dubbo更简单，也更轻量级，学习成本更低，却包含了dubbo大部分能力；thrift和grpc则注重于解决跨语言调用问题，并无解决负载均衡、服务注册与发现等基本问题。

 

karyon/ribbon则没法直接单独使用，须要配合Eureka才能一块儿使用，过于复杂。RPC框架都有一个通用的问题，很难直接对服务端进行测试，因为RPC传输二进制数据，这个数据难以手动构造，直接形成测试复杂，集成复杂。

 

因而，咱们在开源框架的基础之上进行了扩展和重构，为了使RPC框架支持restful，咱们将序列化层和Transport层进行了改造，将序列化层的序列化方式改为了json(rest)，Transport层将netty换成了http client+tomcat，之因此须要将netty换成tomcat的缘由是由于咱们须要一个servlet容器，netty不是一个servlet容器。

 

固然，将二进制数据改为json后，性能会有损耗，可是性能并非咱们追求的惟一目标，咱们系统并不直接面向用户，更多的是企业用户，因此开发效率，研发成本等问题考虑多一些。如下是咱们改造先后motan架构对比：

 

 

RESTFul：轻量级通信的首选方式。在微服务架构下，推崇采用轻量级的方式进行通信，咱们选择RESTFul进行通信，每一个微服务都统一对外暴露RESTFul服务，不管是前端调用后端服务，仍是后端服务间的调用，都统一走RESTFul，这样统一了协议栈；同时还能够很是方便的进行服务的mock，只须要模拟RESTFul请求就能够了，服务间依赖测试难度大大下降，极大的提升了开发人员开发微服务、测试人员测试微服务、集成微服务的效率。依赖于轻量级的RESTFul，在微服务架构中，引入非java语言也是可行的。如下是咱们微服务架构中RESTFul通信的示意图：

 

 

服务注册与发现：微服务架构由一组独立的微服务组成，这些微服务之间如何才能发现彼此？这就要求微服务之间存在一种发现机制，目前咱们经过服务注册与发现来让微服务能够感知彼此，微服务框架在启动的时候，将本身的信息注册到注册中心，同时从注册中心订阅本身须要引用的服务。更多服务注册与发现内容，请移步至《微服务架构实践：服务注册与发现中负载方案选型》（点击标题便可阅读）。如下是咱们基于etcd+motan实现服务注册与发现的架构示意图：

 

 

负载均衡和容错：服务高可用的重要手段。为了保证微服务的高可用，每一个微服务通常会有多个实例服务提供服务，此时须要客户端在进行服务的负载均衡；目前微服务框架中，现支持常见的负载均衡策略，如随机，轮训，hash，权重，链接数，缺省是根据链接数，链接数越少，优先级越高。在调用服务集群的时候，若是一个微服务调用异常，如超时，或者发生链接异常，网络异常，则根据容错策略进行服务容错，目前咱们采用简单的Failover，即选择下一个可用的服务进行调用，目前支持的容错策略有快速失败、失效切换。若是连续失败屡次，则须要直接熔断，再也不发起调用，这样能够防止一个服务异常拖垮全部依赖它的服务；在熔断这个地方，目前咱们作的比较简单，采用简单的策略避免服务不可用，后续会考虑将Netflix 的Hystrix引入到咱们的微服务框架中。

 

限流和降级：保证核心服务的稳定性。为了保证核心系统稳定性，随着访问量的增长，咱们设置了一个系统可以处理的极限阀值，超过这个阀值的请求则直接拒绝。同时，为了保证某些核心服务可用，须要对某些非核心业务进行降级。目前咱们经过限制每一个服务的最大访问量进行限流控制，降级则经过管理控制台对单个服务进行人工降级。如下是服务容错、熔断、限流的示意图：

 

 

权限验证：保障系统的安全。微服务架构推荐以轻量级的通信机制，咱们选择了http+json进行通信，这种通信方式很容易被伪造，所以须要某种机制保证微服务的安全，目前咱们经过token机制保证微服务的安全。用户在登陆的时候会颁发给用户一个token，用户每次访问平台的时候，须要传递此token，后台校验此token的合法性，若是合法则能够访问，若是没有token或者token不合法，则禁止访问。

 

日志是分析问题，定位问题的关键。在微服务架构中，一个客户端请求的接入，每每涉及到后端一系列服务的调用，如何将这些请求串联起来？业界经常使用的方案是采用全局流水号串联起来。咱们也不例外。经过全局流水号，从日志里面能够拉出整条调用链路。目前咱们对不一样的日志进行不一样的分类，每种不一样的日志分类都有固定的格式，方便进行统一监控。目前咱们分了系统日志：记录系统运行的总体状况，系统调用边界状况；审计日志：用于安全审计；跟踪日志：开发人员进行调试，定位问题的日志。在微服务框架中，全部的系统调用边界、请求接入接出边界，都存在统一的日志埋点，这些日志埋点和监控系统对接，能够方便的查看系统的运行各项指标，同时也能够根据日志跟踪到一个服务从前到后的整个调用链路。

 

在实施微服务架构中，以上7个关键点是咱们微服务框架主要解决的问题：RPC作为微服务架构中通信的基础，选择RESTFul作为微服务架构中的轻量级通信机制、统一协议栈，微服务之间的服务发现与注册，容错和负载均衡保证服务的高可用，限流和降级保证核心服务的稳定性，系统的安全及全链路日志跟踪；固然还有其余的一些问题须要关注，不在这一一展开，你们在微服务架构落地的过程当中也能够参考图1中其余的一些关注点。

 

 

3、根据企业自身的业务特色，

能落地的微服务架构就是最佳实践

 

在微服务的浪潮下，大量的新概念不断涌出，新的开源框架不断增多，如何根据企业自身的业务特色，合理的运用开源技术落地微服务架构成为关键。微服务概念提出已久，但却一直缺少最佳实践，笔者认为，在实施微服务架构的过程当中，结合企业自身业务特色落地的微服务架构便是最佳实践。咱们在落地的微服务架构中，也选择了一系列的开源框架，咱们根据本身的业务特色，将开源框架进行重构、扩展，造成一套咱们本身内部的微服务框架。咱们实现的微服务框架的技术栈是spring boot+motan+resteasy，注册中心采用了etcd。开源框架的整合、重构与落地过程其实就是一个不断踩坑填坑的过程，至于选择什么开源框架并不重要，重要的是能根据自身业务的需求，实现一套符合企业自身业务特色的微服务架构，并造成最终企业本身的微服务架构最佳实践。