微服务架构下该如何技术选型呢？( 二 ) _微服务

学会从业务端思考。首先我们需要充分地理解业务，理解用户需求，理解当下需要解决的首要问题，以及可能的风险有哪些，再将目标进行分解，进行具体的技术选型、模型设计、架构设计。
5. 先验证后使用
对于未经验证的新技术、新理念的引入一定要慎重，一定要在全方位的验证过后，再大规模的使用，最终确定选型。新技术、新理念的出现，自然有它的诱惑，慎重并不代表保守，技术总是在不断前进，拥抱变化本身没有问题，但是引入不成熟的技术看似能带来短期的收益，但是它的风险或者是后期的成本可能远远大于收益。
验证后，才有说服力，用着更放心。
三、技术选型
每种技术架构都有其优缺点, 存在即合理, 不同的业务场景使用不同的应用架构，技术框架，不一定说最新的架构、技术就是最适合你的。
微服务架构中常提及到的主要技术框架选型如下表所示，本文后面将基于此展开说明对比。

文章插图
四、服务治理
1.Dubbo
Dubbo 是一款高性能、轻量级的开源 JAVA RPC 框架，以及 SOA 服务治理方案。简单的说，Dubbo 就是个服务框架，说白了就是个远程服务调用的分布式框架。它提供了三大核心能力：面向接口的远程方法调用、智能容错和负载均衡、以及服务自动注册和发现，很容易和 Spring 框架无缝集成。
Dubbo 逻辑架构如下图所示：

文章插图
Provider：暴露服务的提供方，可以通过 jar 或者容器的方式启动服务。
Consumer：调用远程服务的服务消费方。
Registry：服务注册中心和发现中心。
Monitor：统计服务和调用次数，调用时间监控中心。（dubbo 的控制台页面中可以显示，目前只有一个简单版本）
Container：服务运行的容器。
Dubbo 特点：
远程通讯: 提供对多种基于长连接的 NIO 框架抽象封装（非阻塞 I/O 的通信方式，Mina/Netty/Grizzly），包括多种线程模型，序列化（Hessian2/ProtoBuf），以及“请求 - 响应”模式的信息交换方式。
集群容错: 提供基于接口方法的透明远程过程调用（RPC），包括多协议支持（自定义 RPC 协议），以及软负载均衡（Random/RoundRobin），失败容错（Failover/Failback），地址路由，动态配置等集群支持。
自动发现: 基于注册中心目录服务，使服务消费方能动态的查找服务提供方，使地址透明，使服务提供方可以平滑增加或减少机器。
在现有的微服务架构下，Dubbo 只能说是一个服务治理框架，或者说是一个 RPC 框架，是以接口为粒度，一个接口类就就是一个服务。如果直接用 Dubbo 来实现微服务架构，还缺少以下几个功能：
分布式配置：可以使用 Spring Cloud Config、Apollo 等来实现。
链路追踪：可以使用 Zipkin、CAT 等来实现。
批量任务：可以使用当当网开源的 Elastic-Job 来实现。
2.Spring Cloud
Spring Cloud 是目前最主流的微服务架构落地首选方案之一，是基于 Spring Boot 实现的开源框架，是一个全家桶，是微服务的整体技术栈。
Spring Boot 是 Spring 的一套快速配置脚手架，使用默认大于配置的理念，用于快速开发单个微服务。
它为服务注册发现、动态路由、负载均衡、配置管理、消息总线、熔断器、分布式链路追踪、大数据操作等提供了简单的实现，让我们可以更简洁的使用它。
正如我们前面说过的，微服务是可以独立部署、水平扩展、独立访问的服务单元，而 Spring Cloud 就是这些微服务的“大管家”，采用了微服务这种架构之后，项目的数量会非常多，调用链路复杂，从而管理成了很大的问题，而 Spring Cloud 框架恰恰提供了各种组件用于管理和治理微服务。理所应当的，就成了大家首选框架了。
Spring Cloud 的整体架构如下图所示，提供一站式的微服务架构解决方案。

文章插图
使用 Spring Cloud 来构建微服务架构可以省去你整合各家技术的成本，Spring Cloud 为我们构建微服务架构提供了一站式的解决方案，就好比当初 Spring 诞生是为解决 EJB 企业应用开发的众多问题而提供的一站式轻量级企业应用开发解决方案一样，随着使用 Spring Cloud 的产品数量增加，Spring Cloud 在微服务架构中已一统江湖。
下面是 Spring Cloud 的完整技术栈，看完你就知道它为啥会在微服务架构中一统江湖了。