带你读《Spring Cloud微服务:入门、实战与进阶》之一:Spring Cloud 与微服务概述-阿里云开发者社区(en)

 Knowledge center     |      2019-11-07 00:00:00

点击查看第二章
点击查看第三章
Spring Cloud微服务:入门、实战与进阶

image.png

尹吉欢 著

第1章

Spring Cloud 与微服务概述
微服务架构是一种架构风格,而Spring Cloud 是实现微服务架构的一系列框架的有序集合。本章将带你进入神秘的微服务世界,去探索微服务存在的价值及意义,并为阅读后面的章节打下扎实的理论基础。
本书涉及的源码均可在 https://github.com/yinjihuan/spring-cloud 中下载。如果下载失败,也可以发邮件给笔者 jihuan900@126.com,或者关注微信公众号 “猿天地”,直接与笔者交流。

1.1 传统的单体应用

所谓单体应用程序,通俗来说就是把所有功能全部堆积在一起。这个应用大部分都是一个 WAR 包或者 JAR 包。以笔者自己搭建的技术网站“猿天地”为例,用户、文章、源码、课程都是在一个项目中的。随着业务的发展,功能的增加,多年以后这个单体项目将变得越来越臃肿。
这样的单体应用在公司创建初期是一种比较好的方案,要快速增加新功能或部署发布都比较简单。不过,随着时间的推移,危机也会慢慢显露出来。任何一个BUG都可能导致整个应用瘫痪,正所谓牵一发而动全身。

1.1.1 改进单体应用的架构

架构总是通过演变而来的,既然传统的单体应用架构不能满足业务的发展,那么架构的改变必然会提上日程。在系统不能支撑当前的用户量后,我们将项目按照不同的业务来做拆分,分成多个子系统,系统之间通过 Webservice 或者 HTTP 接口来进行交互,这样做的好处是系统不再那么臃肿了。
随着用户量越来越多,系统的压力也随之增长。可能其中某一个模块使用的频率比较高,这个时候就需要对这个模块进行扩展,其实就是多部署几个节点。前面再加一个 Nginx 用于负载均衡,刚开始还没什么大问题,当子系统越来越多的时候,每个子系统前面都要加一层负载,对运维人员来说工作量就增加了,因为要维护的也增多了。

1.1.2 向微服务靠拢

前面讲了这么多,还是不能满足互联网公司快速发展的需求,比如高并发、高可用、高扩展。于是基于之前的架构又改进了一番,引入了阿里巴巴开源的 Dubbo 框架,解决了服务之间的调用问题,服务调用方不再需要关注服务提供方的地址,只要从注册中心获取服务提供方的地址即可。
目前国内很多公司的微服务架构都是基于 Dubbo 构建的,为什么我们要转向 Spring Cloud ?可以从下面几个方面进行分析:
社区的支持:

  • 首先 Spring Cloud 有强大的社区支持, 在 Java 生态圈必定离不开 Spring,且Spring Cloud 的更新频率也越来越高。
  • Dubbo 虽然出自阿里巴巴,但是有很长一段时间没维护了,原因是内部有另一个RPC 的框架 HSF,所以 Dubbo 被抛弃了,不过去年 Dubbo 又重回大众视野,对使用开源框架的用户来说,社区对框架的持续维护非常重要,所以笔者认为 Spring 家族的产品更适合中小型公司。

关注内容:

  • Spring Cloud 关注的是整个服务架构会涉及的方方面面,在 Spring Cloud 中各种组件应有尽有,从而使其具有可快速集成、方便、成本低等优势。
  • Dubbo 关注的更细一些,只针对服务治理,相当于 Spring Cloud 中的一个子集。能和 Dubbo 相互比较的应该是 gRPC,Thrift 之类的框架。

性能问题:

  • 对于性能这块,Dubbo 确实要比 Spring Cloud 好,原因大家也都清楚,Dubbo 基于 Netty 的 TCP 及二进制的数据传输,Spring Cloud 基于 HTTP,HTTP 每次都要创建连接,传输的也是文本内容,自然在性能上有些损耗。
  • Spring Cloud 带来的性能损耗对于大部分应用来说是可以接受的,而它具有的HTTP 风格的 API 交互,在不同的语言中是通用的,且对每个微服务的测试来说是非常方便的,也就是说 Spring Cloud 用小的性能损耗换来了更多好处。当当网在Dubbo 的基础上加上 REST 的支持扩展出目前的 Dubbox 也是这个道理。

1.2 什么是微服务

“微服务”一词来源于Martin Fowler的《Microservices》一文。微服务是一种架构风格,即将单体应用划分为小型的服务单元,微服务之间使用HTTP的API进行资源访问与操作。
在笔者看来,微服务架构的演变更像是一个公司的发展过程,从最开始的小公司,到后来的大集团。大集团可拆分出多个子公司,每个子公司的都有自己独立的业务、员工,各自发展,互不影响,合起来则是威力无穷。

1.2.1 使用微服务架构的优势和劣势

臃肿的系统、重复的代码、超长的启动时间带给开发人员的只有无限的埋怨,丝毫没有那种很舒服的、很流畅的写代码的感觉。他们把大部分时间都花在解决问题和项目启动上面了。
1.优势
使用微服务架构能够为我们带来如下好处:

  • 服务的独立部署:每个服务都是一个独立的项目,可以独立部署,不依赖于其他服务,耦合性低。
  • 服务的快速启动:拆分之后服务启动的速度必然要比拆分之前快很多,因为依赖的库少了,代码量也少了。
  • 更加适合敏捷开发:敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行。服务拆分可以快速发布新版本,修改哪个服务只需要发布对应的服务即可, 不用整体重新发布。
  • 职责专一,由专门的团队负责专门的服务:业务发展迅速时,研发人员也会越来越多,每个团队可以负责对应的业务线,服务的拆分有利于团队之间的分工。
  • 服务可以动态按需扩容:当某个服务的访问量较大时,我们只需要将这个服务扩容即可。
  • 代码的复用:每个服务都提供 REST API,所有的基础服务都必须抽出来,很多的底层实现都可以以接口方式提供。

2.劣势
微服务其实是一把双刃剑,既然有利必然也会有弊。下面我们来谈谈微服务有哪些弊端,以及能采取什么办法避免。

  • 分布式部署,调用的复杂性高:单体应用的时候,所有模块之前的调用都是在本地进行的,在微服务中,每个模块都是独立部署的,通过 HTTP 来进行通信,这当中会产生很多问题,比如网络问题、容错问题、调用关系等。
  • 独立的数据库,分布式事务的挑战:每个微服务都有自己的数据库,这就是所谓的去中心化的数据管理。这种模式的优点在于不同的服务,可以选择适合自身业务的数据,比如订单服务可以用MySQL、评论服务可以用Mongodb、商品搜索服务可以用Elasticsearch。缺点就是事务的问题了,目前最理想的解决方案就是柔性事务中的最终一致性,后面的章节会给大家做具体介绍。
  • 测试的难度提升:服务和服务之间通过接口来交互,当接口有改变的时候,对所有的调用方都是有影响的,这时自动化测试就显得非常重要了,如果要靠人工一个个接口去测试,那工作量就太大了。这里要强调一点,就是API文档的管理尤为重要。
  • 运维难度的提升:在采用传统的单体应用时,我们可能只需要关注一个Tomcat的集群、一个MySQL的集群就可以了,但这在微服务架构下是行不通的。当业务增加时,服务也将越来越多,服务的部署、监控将变得非常复杂,这个时候对于运维的要求就高了。

1.2.2 重构前的准备工作

对于上不上微服务,关键在于公司的发展程度。系统是否真的到了必须做分解的地步?在上微服务之前一定要做好技术选型。用什么框架来构建微服务?公司是否支持重构?这些问题都很重要,没有公司的支持一切都是空谈。你要告诉你的上级为什么要重构,为什么要上微服务,上了之后能解决哪些问题,比如能否提高系统稳定性、能否节约机器资源等。有了明确的目标及计划,我相信这件事必成。
在重构之前,架构师一定要对公司所有的产品做一遍梳理,出一个重构方案,画一个架构图。还要对团队成员进行一次培训,讲讲重构的过程中会遇到哪些技术问题,可采用什么方式解决,在这个过程中大家能学到什么。我相信,对于有成长、有意义的事情,就算加班,大家也会开心的。这些你都不准备好,别人会觉得你没事找事,天天让他加班。
重构时最好采用循序渐进的模式,首先对一个产品进行重构规划,抽出业务服务,再抽出这个产品所依赖的基础服务,基础服务是最为重要的。等一个产品稳定之后,再重构其他产品,把核心业务放到最后面。不要想着一步登天,重构就像堆积木,堆着堆着就高了,一周抽一个微服务,慢慢就都变成微服务了。

1.3 什么是Spring Cloud

Spring Cloud 是一系列框架的有序集合。它利用 Spring Boot 的开发便利性,巧妙地简化了分布式系统基础设施的开发,如服务注册、服务发现、配置中心、消息总线、负载均衡、断路器、数据监控等,这些都可以用 Spring Boot 的开发风格做到一键启动和部署。通俗地讲,Spring Cloud 就是用于构建微服务开发和治理的框架集合(并不是具体的一个框架),主要贡献来自 Netflix OSS。

1.3.1 Spring Cloud模块介绍

Spring Cloud 模块的相关介绍如下:

  • Eureka:服务注册中心,用于服务管理。
  • Ribbon:基于客户端的负载均衡组件。
  • Hystrix:容错框架,能够防止服务的雪崩效应。
  • Feign:Web 服务客户端,能够简化 HTTP 接口的调用。
  • Zuul:API 网关,提供路由转发、请求过滤等功能。
  • Config:分布式配置管理。
  • Sleuth:服务跟踪。
  • Stream:构建消息驱动的微服务应用程序的框架。
  • Bus:消息代理的集群消息总线。

除了上述模块,还有 Cli、Task……。本书只介绍一些常用的模块。
Spring Cloud 是一个非常好的框架集合,它包含的功能模块非常多,这里不可能一一讲解到,凡是在本书中出现的模块都是真实开发中用得到的。对于那些没有在本书中进行讲解的模块,大家也可以自行学习,当然有任何问题也可以咨询笔者。

1.3.2 Spring Cloud版本介绍

相信大家跟笔者一样,在第一次访问 Spring Cloud 官网时一定会有一个疑惑那就是版本太多了,到底哪个是稳定版本?哪个才是自己需要的版本?接下来就给大家简单介绍一下版本的问题。
访问官网 https://projects.spring.io/spring-cloud/#learn 可以看到网页右侧的版本列表,如图1-1 所示。
截至本书完稿时,最新的稳定版本是 Finchley SR2。为什么其中还有 Dalston、Edgware等这些版本?而不是像别的项目那样,版本号采用 1.1、1.2、1.3 这种的格式?因为 Spring Cloud 是一个拥有诸多子项目的大型综合项目,可以说是对微服务架构解决方案的综合套件组件,其中包含的各个子项目都独立进行着内容的迭代与更新,各自维护着自己的发布版本号。
至于怎么选择适合自己的版本,笔者认为,大家可以在接触的时候直接选最新的稳定版本。新版本中的Bug肯定要少,并且更稳定。写作本书的时候,官方发布的Spring Cloud最新稳定版本是 Finchley SR2,所以本书的案例都是基于 Finchley SR2 进行讲解的。不同的版本有不同的功能,对应的每个子模块的版本也不一样,那么如何知道每个大版本下面具体的子模块是什么版本呢?答案就在官网的首页上面,在页面的最下方有一个表格(见表1-1),通过这个表格我们可以清楚地知道 Finchley SR2 对应的 Spring Boot 版本是 2.0.6.RELEASE,Spring-Cloud- Bus 是 2.0.0.RELEASE。

image.png

image.png

1.4 本章小结

Spring Cloud 的诞生对于微服务架构来说简直是如鱼得水,本章主要是对微服务及Spring Cloud 做了一些理论性的讲解,同时介绍了我们为什么要选择 Spring Cloud、Spring Cloud 有哪些内容、使用 Spring Cloud 能够为我们带来什么好处等。下一章我们将学习Spring Boot 框架的使用方法。

(en)