共计 4917 个字符，预计需要花费 13 分钟才能阅读完成。
1. 前言
=========
随着当初互联网行业的倒退，越来越多的框架、中间件、容器等开源技术一直地涌现，更好地来服务于业务，实现业务并解决问题。然而面对泛滥的技术抉择，咱们要如何甄别出适宜本人团队业务的技术呢？对于人来说，鞋子过大，可能影响奔跑的速度，鞋子过小，可能影响身材的成长。技术对于业务也是如此的关系。
所以，绝对于技术的学习、搭建、应用、运维等技能，咱们 对技术的甄别抉择更是重中之重。那么本文要讲的 Dubbox 框架，又是如何在泛滥的服务框架中怀才不遇，被团队选中践行服务之路？
===
2. 服务
======
2.1 为什么要做服务
技术为业务而生，架构也为业务而呈现 。随着业务的倒退、用户量的增长，零碎数量增多，调用依赖关系也变得复杂，为了确保零碎高可用、高并发的要求，零碎的架构也从单体时代缓缓迁徙至服务 SOA 时代， 依据不同服务对系统资源的要求不同，咱们能够更正当的配置系统资源，使系统资源利用率最大化。
零碎架构演进
1. 繁多利用架构
当网站流量很小时，只需一个利用，将所有性能都部署在一起，以缩小部署节点和老本。
此时，用于简化增删改查工作量的 数据拜访框架 (ORM) 是要害。
2. 垂直利用架构
当访问量逐步增大，繁多利用减少机器带来的加速度越来越小，将利用拆成互不相干的几个利用，以晋升效率。
此时，用于减速前端页面开发的 Web 框架(MVC) 是要害。
3. 分布式服务架构
当垂直利用越来越多，利用之间交互不可避免，将外围业务抽取进去，作为独立的服务，逐步造成稳固的服务中心，使前端利用能更疾速的响应多变的市场需求。
此时，用于进步业务复用及整合的 分布式服务框架 (RPC) 是要害。
3. 流动计算架构
当服务越来越多，容量的评估，小服务资源的节约等问题逐步浮现，此时需减少一个调度核心基于拜访压力实时治理集群容量，进步集群利用率。
此时，用于进步机器利用率的 资源调度和治理核心 (SOA) 是要害。
平台随着业务的倒退 从 All in One 环境 就能够满足业务需要（以 Java 来说，可能只是一两个 war 包就解决了）；倒退到需 要拆分多个利用，并且采纳 MVC 的形式 拆散前后端，放慢开发效率；在倒退到服务越来越多，不得不将 一些外围或共用的服务拆分进去 ，提供实时流动监控计算等，其实倒退到此阶段，如果服务拆分的足够精密，并且独立运行，这个时候至多能够 了解为 SOA（Service-Oriented Architecture）架构 了。
===
2.2 服务带来的挑战
当迎来服务 SOA 时代，咱们面临要解决的问题会很多，比方：零碎的复杂度回升、服务依赖关系、服务性能监控、全链路日志、容灾、断路器、限流等 。那么面对这些问题为什么还要做分布式服务呢？ 因为在将来只有砥砺前行，能力走的更高更远。不过看到这些问题不要泄气，先不论这些问题，让咱们一步步来梳理下现存有什么问题，咱们要实现什么指标，问题天然会迎刃而解。
依据当初团队的业务零碎状况，首先咱们要梳理出现存的问题是什么：
那么，在抉择技术框架时，技术框架最根本要解决下面现存问题，同时咱们也要确认出咱们的冀望，要达到的指标是什么：
还有最重要一点，这也是往往很多技术人员进入的误区，“对于技术，不要为了应用而应用，用最简略适合的技术实现解决问题才是邪道”。架构是服务于业务的，能疾速不便的满足业务需要的架构才是好的架构。
没有最好的，只有适宜本人的
2.3 服务将来的趋势
一谈到服务，可能大家很多据说过 SOA、MSA 等服务的概念名词，近几年 MSA 炒的比拟火，其实每一个概念的背地都在解决不同的问题。此类名词的最大特点就是 一解释就懂，一问就不知，一探讨就打架。
SOA、MSA 两者说到底都是对外提供接口的一种架构设计形式。微服务其实就是随着互联网的倒退，简单的平台、业务的呈现，导致 SOA 架构向更细粒度、更通用化水平倒退，就成了所谓的微服务了。以这种说法做为依据，我感觉 SOA 与微服务的区别在于如下几个方面：
微服务与 SOA 有很多相同之处。两者都属于典型的、蕴含松耦合分布式组件的系统结构 。在围绕着服务的概念创立架构这一方面，微服务提供了一种更清晰、定义更良好的形式。 微服务的准则与麻利软件开发思维是高度一致的，而它与 SOA 准则的演变的指标也是雷同的，则缩小传统的企业服务总线开发的高复杂性 。两者之间最要害的区别在于， 微服务专一于以自治的形式产生价值。然而两种架构背地的用意是不同的：SOA 尝试将利用集成，个别采纳地方管理模式来确保各利用可能交互运作。微服务尝试部署新性能，疾速无效地扩大开发团队。它着重于扩散治理、代码再利用与自动化执行。
微服务并不是一种新思维的办法。它更像是一种思维的精炼，一种 SOA 的精细化演进 ，并且更好地利用了先进的技术以解决问题，例如容器与自动化等。所以对于咱们 去抉择服务技术框架时，并不是非黑即白 ，而是针对 SOA、MSA 两种架构设计同时要思考到兼容性， 对于现有平台状况架构设计，退则守 SOA，进则攻 MSA，阶段性抉择适宜的。
===
3. 框架
当初业界比拟成熟的服务框架有很多，比方：Hessian、CXF、Dubbo、Dubbox、Spring Cloud、gRPC、thrift 等技术实现，都能够进行近程调用，具体技术实现优劣参考以下剖析，这也是具体在技术计划抉择过程中的重要依据。
3.1 服务框架比照
Dubbo 是阿里巴巴公司开源的一个 Java 高性能优良的服务框架，使得利用可通过高性能的 RPC 实现服务的输入和输出性能，能够和 Spring 框架无缝集成。不过，略有遗憾的是，据说在淘宝外部，dubbo 因为跟淘宝另一个相似的框架 HSF（非开源）有竞争关系，导致 dubbo 团队曾经遣散，反到是当当网的扩大版本 Dubbox 仍在继续倒退，墙内开花墙外香。其它的一些出名电商如当当、国美保护了本人的分支或者在 dubbo 的根底开发，然而官网的库不足保护，相干的依赖类比方 Spring，Netty 还是很老的版本(Spring 3.2.16.RELEASE, netty 3.2.5.Final), 倒是有些网友写了降级 Spring 和 Netty 的插件。
Dubbox 和 Dubbo 实质上没有区别，名字的含意扩大了 Dubbo 而已，以下扩大进去的性能，也是抉择 Dubbox 很重要的考察点。
Spring Cloud 齐全基于 Spring Boot，是一个十分新的我的项目，2016 年推出 1.0 的 release 版本，目前 Github 上更新速度很快. 尽管 Spring Cloud 工夫最短, 然而相比 Dubbo 等 RPC 框架, Spring Cloud 提供的全套的分布式系统解决方案。Spring Cloud 为开发者提供了在分布式系统（配置管理，服务发现，熔断，路由，微代理，管制总线，一次性 token，全局琐，leader 选举，分布式 session，集群状态）中疾速构建的工具，应用 Spring Cloud 的开发者能够疾速的启动服务或构建利用。它们将在任何分布式环境中工作，包含开发人员本人的笔记本电脑，裸物理机的数据中心，和像 Cloud Foundry 云治理平台。在将来引领这微服务架构的倒退，提供业界规范的一套微服务架构解决方案。
毛病是我的项目很年老，很少见到国内业界有人在生产上成套应用，个别都是只有其中一两个组件。相干的技术文档大部分是英文的，案例也绝对较少，应用的话须要摸索的工夫会长一些。
下图是 Spring Cloud 和 Dubbo 比照：
Spring Cloud 和 Dubbo 比照
Motan 是新浪微博开源的一个 Java 框架。它诞生的比拟晚，起于 2013 年，2016 年 5 月开源。Motan 在微博平台中曾经广泛应用，每天为数百个服务实现近千亿次的调用。与 Dubbo 相比，Motan 在性能方面并没有那么全面，也没有实现特地多的扩大。用的人比拟少，性能和稳定性有待张望。对跨语言调用反对较差，次要反对 java。
Hessian 采纳的是 二进制 RPC 协定，实用于发送二进制数据 。但自身也是一个 Web Service 框架对 RPC 调用提供反对，性能简略，应用起来也不便。 基于 Http 协定进行传输。通过 Servlet 提供近程服务。通过 Hessain 自身提供的 API 来发动申请。响应端依据 Hessian 提供的 API 来承受申请。
Hessian 长处：
rpcx 是 Go 语言生态圈的 Dubbo，比 Dubbo 更轻量，实现了 Dubbo 的许多个性，借助于Go 语言优良的并发个性和简洁语法，能够应用较少的代码实现分布式的 RPC 服务。
gRPC 是 Google 开发的高性能、通用的开源 RPC 框架，其由 Google 次要面向挪动利用开发并基于 HTTP/ 2 协定规范而设计，基于 ProtoBuf(Protocol Buffers)序列化协定开发，且反对泛滥开发语言。自身它不是分布式的，所以要实现下面的框架的性能须要进一步的开发。
thrift 是 Apache 的一个跨语言的高性能的服务框架，也失去了宽泛的利用。
以上 RPC 框架性能比拟：
理论场景中的抉择
3.2 RPC vs REST(JAX-RS)
因为 Dubbo 是根底框架，其实现的内容对于咱们施行微服务架构是否正当，也须要咱们依据本身需要去思考是否要批改，比方 Dubbo 的服务调用是通过 RPC 实现的，然而如果认真拜读过 Martin Fowler 的 microservices 一文，其定义的服务间通信是 HTTP 协定的 REST API。那么这两种有何区别呢？
1. 服务提供方与调用方接口依赖形式太强
咱们为每个微服务定义了各自的 service 形象接口，并通过继续集成公布到公有仓库中，调用方利用对微服务提供的形象接口存在强依赖关系，因而不管开发、测试、集成环境都须要严格的治理版本依赖，才不会呈现服务方与调用方的不统一导致利用无奈编译胜利等一系列问题，以及这也会间接影响本地开发的环境要求，往往一个依赖很多服务的下层利用，每天都要更新很多代码并 install 之后能力进行后续的开发。若没有严格的版本管理制度或开发一些自动化工具，这样的依赖关系会成为开发团队的一大噩梦 。 而 REST 接口相比 RPC 更为轻量化，服务提供方和调用方的依赖只是依附一纸契约，不存在代码级别的强依赖 ，当然 REST 接口也有痛点， 因为接口定义过轻，很容易导致定义文档与理论实现不统一导致服务集成时的问题 ，然而该问题很好解决，只须要通过每个服务整合 swagger， 让每个服务的代码与文档一体化，就能解决。所以在分布式环境下，REST 形式的服务依赖要比 RPC 形式的依赖更为灵便。
2. 服务对平台敏感，难以简略复用
通常咱们在提供对外服务时，都会 以 REST 的形式提供进来，这样能够实现跨平台的特点，任何一个语言的调用方都能够依据接口定义来实现。那么在 Dubbo 中咱们要提供 REST 接口时，不得不实现一层代理，用来将 RPC 接口转换成 REST 接口进行对外公布。若咱们每个服务自身就以 REST 接口方式存在，当要对外提供服务时，次要在 API 网关中配置映射关系和权限管制就可实现服务的复用了。
置信这些痛点也是为什么当当网在 dubbox（基于 Dubbo 的开源扩大）中减少了对 REST 反对的起因之一。
Dubbo 实现了服务治理的根底，然而要实现一个齐备的微服务架构，还须要在各环节去扩大和欠缺以保障集群的衰弱，以加重开发、测试以及运维各个环节上减少进去的压力，这样能力让各环节人员真正的专一于业务逻辑。
而 Spring Cloud 仍然发挥了 Spring Source 整合所有的风格，以标准化的姿势将一些微服务架构的成熟产品与框架揉为一体，并继承了 Spring Boot 简略配置、疾速开发、轻松部署的特点，让本来简单的架构工作变得绝对容易上手一些。
所以，如果抉择 Dubbo 请务必在各个环节做好整套解决方案的筹备，不然很可能随着服务数量的增长，整个团队都将疲于应酬各种架构上有余引起的艰难。而如果抉择 Spring Cloud，相对来说每个环节都曾经有了对应的组件反对，可能有些也不肯定能满足你所有的需要，然而其沉闷的社区与高速的迭代进度也会是你能够依附的弱小后盾。
微服务结构图
4. Dubbox 带来什么
=================
4.1 Dubbo 服务治理
Dubbo 服务治理
