微服务和Spring Cloud
文章目录
- 微服务架构概述
-
- 应用架构的发展
-
- 单体架构
- 分布式架构
- 面向服务的SOA架构
- 微服务架构
- 微服务解决方案
-
- 基于Spring Cloud的微服务解决方案
- 基于Dubbo实现微服务解决方案
- 中间件
- Spring Cloud
-
- Spring Cloud项目模块
-
- Spring Cloud与服务治理中间件
- Spring Cloud与配置中心中间件
- Spring Cloud与网关中间件
- Spring Cloud与全链路监控中间件
曾经的单体应用环境：在业务简单、团队组织成员很少的时候，我们常常把功能都集中于一个应用中，统一部署，统一测试，玩得不亦乐乎。但随着业务迅速发展，组织成员日益增多，我们会将所有的功能集中到一个Tomcat中去，每当更新一个功能模块时，势必要更新所有程序，搞不好，还要牵一发动全身，实在难以维护。在单体应用满足不了我们逐渐增长的扩展需求之后，微服务应运而生。它将原来集中于一体的功能拆分出去，比如商品功能、订单功能、用户功能，使其自成体系地发布、运维等，从而解决了单体应用中功能过多、不便维护的弊端。
在2014年底，Spring团队推出Spring Cloud，目标使其成为Java领域微服务架构落地的标准，发展至今，Spring Cloud已经成为Java领域落地微服务架构的完整解决方案。
微服务架构概述
应用架构的发展
应用是可独立运行的程序代码，提供相对完善的业务功能。目前软件架构有三种架构类型，分别是业务架构、应用架构、技术架构。它们之间的关系是业务架构决定应用架构，技术架构支撑应用架构。
架构的发展历程是从单体架构、分布式架构、SOA架构再到微服务架构。
单体架构
一个应用程序将所有的代码集中在一起，例如一个完整的Java Web应用。
单体架构的优点：
- 易于开发：开发人员使用当前开发工具在短时间内就可以开发出单体应用。
- 易于测试：因为不需要依赖其他接口，测试可以节约很多时间。
- 易于部署：你只需要将目录部署在运行环境中即可。
单体架构的缺点：
- 灵活度不够：如果程序有任何修改，修改的不只是一个点，而是自上而下地去修改，测试时必须等到整个程序部署完后才能看出效果。在开发过程可能需要等待其他开发人员开发完成后才能完成部署，降低了团队的灵活性。
- 降低系统的性能：原本可以直接访问数据库但是现在多了一层。即使只包含一个功能点，也需要在各个层写上代码。
- 系统启动慢：一个进程包含了所有业务逻辑，涉及的启动模块过多，导致系统的启动时间延长。
分布式架构
简单来说，按照业务垂直切分，每个应用都是单体架构，通过API互相调用。
面向服务的SOA架构
面向服务的架构（SOA：Service-Oriented Architecture）是一种软件体系结构，其应用程序的不同组件通过网络上的通信协议向其他组件提供服务或消费服务，所以也是一种分布式架构。
简单来说，SOA是不同业务建立不同的服务，服务之间的数据交互粗粒度可以通过服务接口分级，这样松散耦合提高服务的可重用性，也让业务逻辑变得可组合，并且每个服务可以根据使用情况做出合理的分布式部署，从而让服务变得规范，高性能，高可用。
SOA架构中有两个主要角色：服务提供者（Provider）和服务消费者（Consumer）。
阿里开源的Dubbo是SOA的典型实现。
SOA架构的优点：
- 把模块拆分，使用接口通信，降低模块之间的耦合度。
- 把项目拆分成若干个子项目，不同的团队负责不同的子项目。
- 增加功能时只需要增加一个子项目，调用其他系统的接口即可。
- 可以灵活地进行分布式部署。
SOA架构的缺点：
- 系统之间的交互需要使用远程通信，接口开发增加工作量。
微服务架构
微服务架构在某种程度上是SOA架构继续发展的下一步。微服务的概念最早源于Martin Fowler的一篇文章《Microservices》。总体来说，微服务是一种架构风格，对于一个大型复杂的业务系统，它的业务功能可以拆分为多个相互独立的微服务，各个微服务之间是松耦合的，通过各种远程协议进行同步/异步通信，各微服务均可以被独立部署、扩/缩容以及升/降级。
下表对微服务技术选型做了对比：
| – | Spring Cloud | Dubbo | Motan | MSEC | 其他 |
|---|---|---|---|---|---|
| 功能 | 微服务完整方案 | 服务治理框架 | 服务治理框架 | 服务开发运营框架 | 略 |
| 通信方式 | REST/Http | RPC协议 | RPC/Hessian2 | Protocol buffer | grpc、thrift |
| 服务发现/注册 | Eureka（AP） | ZK，Nacos | ZK/Conusl | 只有服务发现 | Etcd |
| 负载均衡 | Ribbon | 客户端负载 | 客户端负载 | 客户端负载 | Nginx+Lua |
| 容错机制 | 6种容错策略 | 6种容错策略 | 2种容错策略 | 自动容错 | Keepalived、HeartBeat |
| 熔断机制 | Hystrix | 无 | 无 | 提供过载保护 | 无 |
| 配置中心 | Spring Cloud Config | Nacos | 无 | 无 | Apollo，Nacos |
| 网关 | Zuul，Gateway | 无 | 无 | 无 | Kong、自研 |
| 服务监控 | Hystrix+Turbine | Dubbo+Monitor | 无 | Monitor | ELK |
| 链路监控 | Sleuth+Zipkin | 无 | 无 | 无 | Pinpoint |
| 多语言 | Rest支持多语言 | Java | Java | Java, C++, PHP | Java, PHP, Node.js |
| 社区活跃 | 高（背靠Spring） | 高（背靠阿里） | 一般 | 未知 | 略 |
微服务解决方案
采用微服务构建系统也会带来更清晰的业务划分和可扩展性。同时支持微服务的技术栈也是多种多样的。
基于Spring Cloud的微服务解决方案
Spring Cloud的技术选型是中立的，因此可以随需更换搭配使用，基于SpringCloud的微服务落地解决方案可以分为三种：
| 组件 | 方案1 | 方案2 | 方案3 |
| 服务发现 | Eureka | Consul | etcd、阿里Nacos |
| 共用组件 | 服务间调用组件Feign、负载均衡组件Ribbon、熔断器Hystrix | ||
| 网关 | 性能低：Zuul；性能高：Spring Cloud Gateway | 自研网关中间件 | |
| 配置中心 | Spring Cloud Config、携程阿波罗、阿里Nacos | ||
| 全链路监控 | zipkin（不推荐）、Pinpoint（不推荐）、Skywalking（推荐） | ||
| 搭配使用 | 比如分布式事务、容器化、Spring Cloud 与DDD、gRPC | ||
基于Dubbo实现微服务解决方案
2012年，阿里巴巴在GitHub上开源了基于Java的分布式服务治理框架Dubbo，但是Dubbo未来的定位并不是要成为一个微服务的全面解决方案，而是专注于RPC领域，成为微服务生态体系中的一个重要组件。
至于微服务化衍生出的服务治理需求，Dubbo正在积极适配开源解决方案，并且已经启动独立的开源项目予以支持，比如最近宣布的开源的Nacos。Nacos的定位是一个更易于帮助构建云原生应用的动态服务发现、配置和服务管理平台。
因此基于Dubbo的微服务解决方案是：Dubbo+Nacos+其他
中间件
中间件 百度百科
中间件向下屏蔽异构的硬件、软件、网络等计算资源，向上提供应用开发、运行、维护等全生命周期的统一计算环境与管理，属于承上启下的中间连接层，对企业来说有着极其重要的价值。
Spring Cloud
Spring Cloud也是一个中间件。它目前由Spring官方开发维护，基于Spring Boot开发，提供一套完整的微服务解决方案。
包括服务注册与发现、配置中心、全链路监控、API网关、熔断器等选型中立的开源组件，可以随需扩展和替换组装。
Spring Cloud项目模块
Spring Cloud是一个开源项目集合，包括很多子项目。具体的项目地址可以参考GitHub组织：
http://github.com/spring-cloud
Spring Cloud与服务治理中间件
服务治理中间件包含服务注册与发现、服务路由、负载均衡、自我保护、丰富的治理管理机制等功能。其中服务路由包含服务上下线、在线测试、机房就近选择、A/B测试、灰度发布等。负载均衡支持根据目标状态和目标权重进行负载均衡。自我保护包括服务降级、优雅降级和流量控制。
Spring Cloud作为一个服务治理中间件，它的服务治理体系做了高度的抽象，目前支持使用Eureka、Zookeeper、Consul作为注册中心，并且预留了扩展接口，而且由于选型是中立的，所以支持无缝替换。
关于SpringCloud注册中心的对比选型参考：
| Feature | Consul | Zookeeper | etcd | Euerka |
|---|---|---|---|---|
| 服务健康检查 | 服务状态,内存，硬盘等, | (弱)长连接，keepalive | 连接心跳 | 可配支持 |
| 多数据中心 | 支持 | - | - | - |
| kv存储服务 | 支持 | 支持 | 支持 | - |
| 一致性 | raft | paxos | raft | - |
| cap | ca | cp | cp | ap |
| 使用接口(多语言能力) | 支持http和dns | 客户端 | http/grpc | http(sidecar) |
| watch支持 | 全量/支持polling | 支持 | 支持long polling | 支持long polling/大部分增量 |
| 自身监控 | metrics | - | metrics | metrics |
| 安全 | acl/https支持(弱) | acl | https支持(弱) | - |
| SpringCloud集成 | 已支持 | 已支持 | 已支持 | 已支持 |
Spring Cloud与配置中心中间件
Spring Cloud Config是Spring Cloud生态圈中的配置中心中间件，它把应用原本放在本地文件中的配置抽取出来放在中心服务器，从而能够提供更好的管理、发布能力。Spring Cloud Config基于应用、环境、版本三个维度管理，配置存储支持Git和其他扩展存储，且无缝支持Spring里Environment和PropertySource的接口。但是Spring Cloud Config的缺点是没有可视化的管控平台，因此会用其他的配置中心中间件取代它管理配置
Spring Cloud与网关中间件
网关中间件概述API Gateway（APIGW/API网关），顾名思义，是出现在系统边界上一个面向API的、串行集中式的强管控服务，这里的边界是企业IT系统的边界，可以理解为企业级应用防火墙，主要起到隔离外部访问与内部系统的作用。
随着微服务架构概念的提出，API网关成为微服务架构的一个标配组件。作为一个网关中间件，至少具备如下四大功能。
（1）统一接入功能
（2）协议适配功能
（3）流量管控功能：网关作为所有请求流量的入口
（4）安全防护功能
Spring Cloud第一代网关Zuul
Spring Cloud第二代网关 Gateway
Spring Cloud Gateway是Spring官方基于Spring5.0、Spring Boot 2.0和Project Reactor等技术开发的网关，旨在为微服务架构提供一种简单、有效、统一的API路由管理方式。Spring CloudGateway底层基于Netty实现（Netty的线程模型是多线程reactor模型，使用boss线程和worker线程接收并异步处理请求，具有很强大的高并发处理能力），因此Spring Cloud Gateway出现的目的就是替代Netflix Zuul。其不仅提供统一的路由方式，并且基于Filter链的方式提供了网关基本的功能，例如，安全、监控/埋点、限流等。
Spring Cloud与全链路监控中间件
利用全链路监控中间件收集、汇总并分析日志信息，进行可视化展示和监控告警。
全链路监控中间件应该提供的主要功能包括：
- 定位慢调用：包括慢Web服务（包括Restful Web服务）、慢REST或RPC服务、慢SQL。
- 定位各种错误：包括4× ×、5× ×、Service Error。
- 定位各种异常：包括Error Exception、Fatal Exception。
- 展现依赖和拓扑：域拓扑、服务拓扑、trace拓扑。
- Trace调用链：将端到端的调用，以及附加在这次调用的上下文信息，异常日志信息，每一个调用点的耗时都呈现给用户进行展示。
- 应用告警：根据运维设定的告警规则，扫描指标数据，如违反告警规则，则将告警信息上报到中央告警平台。
如果使用Java技术栈，希望采用非侵入式的监控，推荐使用Pinpoint或者Skywalking。