微服务 | 资深架构师解读如何使用微服务架构

Posted 2021-04-14 码上有猿

码神联盟

工作13年的架构师和你一起聊技术

长按下方扫码可入群、关注

备注：本文7000多字，可先收藏在阅读，精心总结，切勿盗权，认真读后，定会受益匪浅

前言

    微服务架构是近几年互联网很热门的话题，是互联网技术发展的必然途径，它的存在主要是将单一的应用程序拆分成一个个细小的服务，使得服务之间相互配合，相互调用，相互服务，到目前为止，微服务架构虽层出不穷，但是还没有一套公认的技术标准和实现规范，不过，目前还是有一些具有很强影响力的开源的微服务架构技术，维护和提升了微服务的技术规范思路，比如Dubbo和Spring Cloud。

为什么要用微服务

    在分析梳理微服务架构和组件之前，我们来看下，什么要用微服务？

    随着互联网行业的发展，越来越多的框架、技术、中间件、容器不断的涌现，更好的服务于业务，但是面对众多的技术框架，如何甄别出符合自己的业务技术，这就是技术选型，技术选型选的好，业务实现会事半功倍，选型存在问题，则搬起石头砸自己的脚，就比如穿鞋子，鞋子太大，可能影响你走路姿势，如果鞋子太小，则影响你生长发育。

    技术为业务而生，架构也为业务而出现，随着业务的不断扩展，用户量的增长，系统数量增加，各服务之间调用依赖关系变得复杂，为了确保系统的稳定性，健壮性，扩展性，维护性以及高可用、高并发、高海量(三高)的要求，系统的架构也从单一的时代迁移至SOA服务时代，根据不同的服务对不同的系统资源的使用，合理的配置系统资源，提高资源利用率。

系统架构演变

1：单体应用架构

    当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。

    此时，用于简化增删改查工作量的 数据访问框架(ORM) 是关键。

2：垂直应用架构

    当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率。

    此时，用于加速前端页面开发的 Web框架(MVC) 是关键。

3：分布式服务架构

    当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。

    此时，用于提高业务复用及整合的 分布式服务框架(RPC) 是关键。

4：流动服务架构

    当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。

    此时，用于提高机器利用率的 资源调度和治理中心(SOA) 是关键。

常见架构问题

    当服务越来越多，我们面临的解决问题也会很多，比如：系统的复杂度提升、服务依赖关系复杂、服务性能监控、链路日志分析、容灾、容错、熔断机制、断路器、限流等等。那么既然会有这么多问题出现，为什么还需要使用分布式服务呢？因为都不用，则技术就停滞不前了。接下来，我们逐个梳理下这些问题。

1：多种调用传输方式

    问题：Websense服务、HTTPS服务

2：服务调用依赖关系

    问题：人工记录、源码分析、文档记录

3：服务调用性能监控

    问题：日志记录、人工分析、实时监测

4：服务与应用耦合度

    问题：服务down掉、系统崩溃

5：服务集群负载配置

    问题：nginx配置、代理设置、单点问题、资源加速、网关配置

系统需要支持或者达到的目标：

    1：支持当前业务需求，这是最基本的条件

    2：服务避免单点、去服务中心化

    3：服务高可用、高并发、解决耦合依赖问题

    4：服务通用化、高扩展、高性能、支持异构系统的调用

    5：服务依赖自动化、可视化

    6：服务需自带注册、发现、订阅、检查、负载均衡等特性

    7：简单轻量、易开发、低侵入、安全性高

最重要的一点，也是很多技术工程师误区的一点，就是“对于技术，不要为了使用而使用，而是用最简单的技术去实现或解决问题才是根本”，也是康哥经常提到的“简单是科学的根本”，架构是服务于业务的，符合、实现、解决自己的业务架构，才是好架构。跟找媳妇是一个道理，不是所有漂亮的姑娘，你都要娶家里来。

SOA和微服务区别

谈到微服务，可能大家听过的最多的就是Dubbo、Cloud、SOA等概念，此类名词的通病就是：一读就知、一问就懵、一解释就懂、一讨论就掐。

这些说到底就是对外提供服务(接口)的一种架构设计模式，微服务的出现，会将平台或者业务导向更细粒化、通用化的方向发展，这就形成了微服务，那么SOA和微服务的区别到底在哪？这也是很多架构师面试的时候，被问到的问题，那么我们一起来总结下：

1：细粒化

    微服务相对于SOA更加细粒(微服务更多接口是独立的进程存在，互不影响)

2：通用化

    微服务的接口更加通用化(eg：HTTP RESTful方式，各终端都可以调用，和平台、语言无关)

3：中心化

    微服务更倾向于分布式中心化部署(适合互联网项目)，微服务的原则和敏捷开发思想高度一致，可以减少企业服务总线开发的复杂性

4：价值化

    微服务专注于以自治的方式产生价值，倡导分散管理，自动化执行，而SOA尝试将应用集成，一般采用中央管理模式来确保各应用能够交互运作

功能	SOA	微服务
组件大小	整体业务逻辑	单独业务逻辑
耦合度	通常松耦合	总是松耦合
公司架构	任何类型	小型、交叉频繁团队
管理	中央管理	分散管理
目标	应用可以交互操作	新功能，快速扩展

各大微服务框架区别

目前，比较成熟的微服务框架有：Hessian、CXF、Dubbo、Dubbox、Spring Cloud、gRPC、thrift等技术。都可以进行RPC远程调用，那么这些框架区别到底如何？我们具体分析如下：

首先看下RPC框架功能对比：

功能	Hessian	RPCX	gRPC	Thrift	Dubbo	DubboX	SpringCloud
开发语言	跨语言	GO	跨语言	跨语言	Java	Java	Java
分布式(服务治理)	×	√	×	×	√	√	√
多序列化框架支持	Hessian	√	×只支持protobuf	×支持thrift	√	√	√
多种注册中心	×	√	×	×	√	√	√
管理中心	×	√	×	×	√	√	√
跨编程语言	√	×	√	√	×	×	×
支持REST	×	×	×	×	×	√	√
关注度	低	低	中	中	中	高	中
上手难度	低	中	中	中	低	低	中
运维成本	低	中	中	低	中	中	中
开源机构	Caucho	Apache	Google	Apache	Alibaba	Dangdang	Apache

Dubbo：

    Dubbo 是阿里巴巴公司开源的一个Java高性能优秀的服务框架，使得应用可通过高性能的 RPC 实现服务的输出和输入功能，可以和 Spring框架无缝集成。

DubboX：

    Dubbox和Dubbo本质上没有区别，名字的含义扩展了Dubbo而已，为Dubbo实现了一些新的功能，并将其命名为Dubbox（即Dubbo eXtensions）。

DubboX主要的新功能包括：

1：支持REST风格远程调用（HTTP + JSON/XML)：

        基于非常成熟的JBoss RestEasy框架，在dubbo中实现了REST风格（HTTP + JSON/XML）的远程调用，以显著简化企业内部的跨语言交互，同时显著简化企业对外的Open API、无线API甚至AJAX服务端等等的开发。事实上，这个REST调用也使得Dubbo可以对当今特别流行的“微服务”架构提供基础性支持。 另外，REST调用也达到了比较高的性能，在基准测试下，HTTP + JSON与Dubbo 2.x默认的RPC协议（即TCP + Hessian2二进制序列化）之间只有1.5倍左右的差距。

2：支持基于Kryo和FST的Java高效序列化实现：

    基于当今比较知名的Kryo和FST高性能序列化库，为Dubbo 默认的RPC协议添加新的序列化实现，并优化调整了其序列化体系，比较显著的提高了Dubbo RPC的性能。

3：支持基于嵌入式Tomcat的HTTP remoting体系：

    基于嵌入式tomcat实现dubbo的HTTP remoting体系（即dubbo-remoting-http），用以逐步取代Dubbo中旧版本的嵌入式Jetty，可以显著的提高REST等的远程调用性能，

并将Servlet API的支持从2.5升级到3.1。（注：除了REST，dubbo中的WebServices、Hessian、HTTP Invoker等协议都基于这个HTTP remoting体系）。

4：升级Spring：

    将dubbo中Spring由2.x升级到目前最常用的3.x版本，减少项目中版本冲突带来的麻烦。

5：升级ZooKeeper客户端：

    将dubbo中的zookeeper客户端升级到最新的版本，以修正老版本中包含的bug。

Spring Cloud：

    Spring Cloud完全基于Spring Boot，是一个非常新的项目，2016年推出1.0的release版本，目前Github上更新速度很快. 虽然Spring Cloud时间最短, 但是相比Dubbo等RPC框架, Spring Cloud提供的全套的分布式系统解决方案。Spring Cloud 为开发者提供了在分布式系统（配置管理，服务发现，熔断，路由，微代理，控制总线，一次性token，全局琐，leader选举，分布式session，集群状态）中快速构建的工具，使用Spring Cloud的开发者可以快速的启动服务或构建应用．它们将在任何分布式环境中工作，包括开发人员自己的笔记本电脑，裸物理机的数据中心，和像Cloud Foundry云管理平台。在未来引领这微服务架构的发展，提供业界标准的一套微服务架构解决方案。

Hessian：

    Hessian采用的是二进制RPC协议，适用于发送二进制数据。但本身也是一个Web Service框架对RPC调用提供支持，功能简单，使用起来也方便。基于Http协议进行传输。通过Servlet提供远程服务。通过Hessain本身提供的API来发起请求。响应端根据Hessian提供的API来接受请求。

rpcx：

    rpcx是Go语言生态圈的Dubbo， 比Dubbo更轻量，实现了Dubbo的许多特性，借助于Go语言优秀的并发特性和简洁语法，可以使用较少的代码实现分布式的RPC服务。

gRPC：

    gRPC是Google开发的高性能、通用的开源RPC框架，其由Google主要面向移动应用开发并基于HTTP/2协议标准而设计，基于ProtoBuf(Protocol Buffers)序列化协议开发，且支持众多开发语言。本身它不是分布式的，所以要实现上面的框架的功能需要进一步的开发。

Thrift：

    thrift是Apache的一个跨语言的高性能的服务框架，也得到了广泛的应用。

微服务优势

讲述了这么多，那么微服务的优势有哪些？

1：降低复杂度

    将原来偶合在一起的复杂业务拆分为单个服务，规避了原本复杂度无止境的积累。每一个微服务专注于单一功能，并通过定义良好的接口清晰表述服务边界。每个服务开发者只专注服务本身，通过使用缓存、DAL等各种技术手段来提升系统的性能，而对于消费方来说完全透明。

2：可独立部署

    由于微服务具备独立的运行进程，所以每个微服务可以独立部署。当业务迭代时只需要发布相关服务的迭代即可，降低了测试的工作量同时也降低了服务发布的风险。

3：容错

    在微服务架构下，当某一组件发生故障时，故障会被隔离在单个服务中。 通过限流、熔断等方式降低错误导致的危害，保障核心业务正常运行。

4：扩展

    单块架构应用也可以实现横向扩展，就是将整个应用完整的复制到不同的节点。当应用的不同组件在扩展需求上存在差异时，微服务架构便体现出其灵活性，因为每个服务可以根据实际需求独立进行扩展。

Dubbo和SpringCloud对比

   

微服务架构Dubbo和Spring Cloud框架对比：

    那么接下来，我们还是把重点放到目前比较认可流行的微服务架构Dubbo和Spring Cloud上面，将通过技术选型、通讯协议、服务依赖、模式等几个方面，综合比较下这2中框架，便于结合自身公司业务的特点，选择合适的微服务架构，稳定的实施项目的微服务开发。

一：核心部件

Dubbo：

    Provider：暴露服务的提供者

    Consumer：调用远程服务的消费者

    Registry：服务注册中心和发现中心

    Monitor：监控中心

    Container：服务运行的容器

Spring Cloud：

    Service Provider： 暴露服务的提供方。

    Service Consumer：调用远程服务的服务消费方。

    EureKa Server： 服务注册中心和服务发现中心。

结论：从整体架构上来看，二者模式接近，都需要需要服务提供方，注册中心，服务消费方。

二：核心要素

    Dubbo只是实现了服务治理，而Spring Cloud子项目分别覆盖了微服务架构下的众多部件，而服务治理只是其中的一个方面。Dubbo提供了各种Filter，对于上述中“无”的要素，可以通过扩展Filter来完善。

核心要素	Dubbo	Spring Cloud
服务注册中心	Zookeeper、Redis	Eureka
服务调用方式	RPC	REST API
服务网关	无	Zuul
断路器	不完善	Hystrix
分布式配置	无（可以使用淘宝的diamond百度的disconf）	Config
分布式追踪系统	无（京东开源的Hydra）	Sleuth
消息总线	无	Bus
数据流	无	Stream，基于Redis、Kafka、MQ实现的消息微服务
批量任务	无(当当开源的Elastic-Job、tbschedule)	Task

结论：从核心要素来看，Spring Cloud 更胜一筹，在开发过程中只要整合Spring Cloud的子项目就可以顺利的完成各种组件的融合，而Dubbo缺需要通过实现各种Filter来做定制，开发成本以及技术难度略高。

三：通讯协议

Dubbo：

    Dubbo使用RPC协议进行通讯，缺省协议采用单一的长连接和NIO异步通讯，适合用于小数据量、大并发的服务调用，或者服务消费者机器数远远大于服务提供者机器数的场景。

    Dubbo内部采用Jetty 作为服务器实现。

Hessian：

    Hessian协议用于集成Hessian的服务，底层采用的是HTTP通讯，采用Servlet来暴露服务，而Http采用的是Spring的HttpInvoker实现。

WebService：

    基于CXF的实现。

Spring Cloud：

    使用的是HTTP协议的REST API。

四：性能比较

    举个栗子：某个POJO对象，有10个属性，请求10W次，Dubbo和Spring Cloud在不同的线程数量下(并发量)，每次请求耗时对比情况。

线程数	Dubbo	Spring Cloud
10线程	2.75	6.52
20线程	4.18	10.03
50线程	10.3	28.14
100线程	20.13	55.23
200线程	42	110.21

数据来源于官网测试数据

说明：客户端和服务器配置均采用阿里云的ECS服务器，4G 8核配置，Dubbo采用默认的dubbo协议。

总结：dubbo支持各种通信协议，而且消费方和服务方使用长链接方式交互，通信速度上略胜Spring Cloud，如果对于系统的响应时间有严格要求，长链接更合适

五：服务依赖方式

Dubbo：

    服务提供方与消费方通过接口的方式依赖，服务调用设计如下：

        interface层：服务接口层，定义了服务对外提供的所有接口

        Molel层：服务的DTO对象层

        business层：业务实现层，实现interface接口并且和DB交互

    需要为每个微服务定义了各自的interface接口，并通过持续集成发布到私有仓库中，调用方应用对微服务提供的抽象接口存在强依赖关系，开发、测试、集成环境都需要严格的管理版本依赖。

    通过maven的install & deploy命令把interface和Model层发布到仓库中，服务调用方只需要依赖interface和model层即可。在开发调试阶段只发布Snapshot版本。等到服务调试完成再发布Release版本，通过版本号来区分每次迭代的版本。通过xml配置方式即可方面接入dubbo，对程序无入侵。

Spring Cloud：

服务提供方和服务消费方通过json方式交互，因此只需要定义好相关json字段即可，消费方和提供方无接口依赖。通过注解方式来实现服务配置，对于程序有一定入侵。

总结：Dubbo服务依赖略重，需要有完善的版本管理机制，但是程序入侵少。而Spring Cloud通过Json交互，省略了版本管理的问题，但是具体字段含义需要统一管理，自身Rest API方式交互，为跨平台调用奠定了基础。

六：组件运行流程

Dubbo组件运行流程：

    GateWay：前置网关，具体业务操作，gateWay通过dubbo提供的负载均衡机制自动完成

    Service：原子服务，只提供该业务相关的原子服务

    Zookeeper：原子服务注册到zk上

图中的每个组件都是需要部署在单独的服务器上，gateway用来接受前端请求、聚合服务，并批量调用后台原子服务。每个service层和单独的DB交互。

Spring Cloud组件运行流程：

    1. 所有请求都统一通过 API 网关（Zuul）来访问内部服务

    2. 网关接收到请求后，从注册中心（Eureka）获取可用服务。

    3. 由 Ribbon 进行均衡负载后，分发到后端的具体实例。

    4. 微服务之间通过 Feign 进行通信处理业务。

总结：业务部署方式相同，都需要前置一个网关来隔绝外部直接调用原子服务的风险。Dubbo需要自己开发一套API 网关，而Spring Cloud则可以通过Zuul配置即可完成网关定制。使用方式上Spring Cloud略胜一筹。

微服务架构组成和注意事项

架构组成：

    到底使用是dubbo还是Spring Cloud其实并不重要，重点在于如何合理的利用微服务。下面是一张互联网通用的架构图,其中每个环节都是微服务的核心部分。

分解讲述：

网关集群：数据的聚合、实现对接入客户端的身份认证、防报文重放与防数据篡改、功能调用的业务鉴权、响应数据的脱敏、流量与并发控制等

业务集群：一般情况下移动端访问和浏览器访问的网关需要隔离，防止业务耦合

Local Cache：由于客户端访问业务可能需要调用多个服务聚合，所以本地缓存有效的降低了服务调用的频次，同时也提示了访问速度。本地缓存一般使用自动过期方式，业务场景中允许有一定的数据延时。

服务层：原子服务层，实现基础的增删改查功能，如果需要依赖其他服务需要在Service层主动调用

Remote Cache：访问DB前置一层分布式缓存，减少DB交互次数，提升系统的TPS

DAL：数据访问层，如果单表数据量过大则需要通过DAL层做数据的分库分表处理。

MQ：消息队列用来解耦服务之间的依赖，异步调用可以通过MQ的方式来执行

数据库主从：服务化过程中毕竟的阶段，用来提升系统的TPS

注意事项：

• 服务启动方式建议使用jar方式启动，启动速度快，更容易监控

•  缓存，系统中能使用缓存的地方尽量使用缓存，通过合理的使用缓存可以有效的提高系统的TPS

• 服务拆分要合理，尽量避免因服务拆分而导致的服务循环依赖

• 合理的设置线程池，避免设置过大或者过小导致系统异常

总结

Dubbo出生于阿里系，是阿里巴巴服务化治理的核心框架，并被广泛应用于中国各互联网公司；只需要通过Spring配置的方式即可完成服务化，对于应用无入侵。设计的目的还是服务于自身的业务为主。虽然阿里内部原因dubbo曾经一度暂停维护版本，但是框架本身的成熟度以及文档的完善程度，完全能满足各大互联网公司的业务需求。如果我们需要使用配置中心、分布式跟踪这些内容都需要自己去集成，这样无形中增加了使用 Dubbo 的难度。

Spring Cloud 是大名鼎鼎的 Spring 家族的产品， 专注于企业级开源框架的研发。 Spring Cloud 自从发展到现在，仍然在不断的高速发展，几乎考虑了服务治理的方方面面，开发起来非常的便利和简单。

Dubbo于2017年开始又重启维护，发布了更新后的2.5.6版本，目前最新版本为2.6.5版本，而Spring Cloud更新的非常快，目前已经更新到2.0.2.RELEASE。因此，企业需要根据自身的研发水平和所处阶段选择合适的架构来解决业务问题，不管是Dubbo还是Spring Cloud都是实现微服务有效的工具。

---

▼

码神联盟

微信号：lk591566764

推荐理由：

工作13年的架构师和你一起聊技术，专注于JAVA、数据库、高并发、负载、集群、解决方案、微服务、运维、性能调优、热点开源技术框架等领域；不定期的进行课程直播、技术分享课、技术群等。

 ▼长按下方↓↓↓二维码识别关注