SpringCloud
1: 微服务简介
1.1 SOA
我相信很多人跟我一样看的一脸懵逼。
SOA不是具体的什么技术,而是一种开发项目的思想,这种思想开发的项目有很多好处,更符合现在的互联网系统快速发展的时代。下面举个栗子
设计:比如现我有一个数据库,一个JavaWeb(或者PHP等)的网站客户端,一个安卓app客户端,一个IOS客户端。现在我要给用户提供一个注册账号的功能。
不用SOA的设计思想的实现:JavaWeb里面写一个注册账号的功能,安卓app里面写一个注册账号的功能,IOS同样如此。那么这样的实现有没有什么问题呢?比如有一天,我的注册方法需要改动,那是不是三个地方都要改,而且要改的一模一样。当然问题不止这一个。
SOA的设计思想实现:用Java(或者是其他语言皆可)单独创建一个工程部署在一台服务器上,并且写一个方法(或称函数)执行上述注册操作,然后提供一个借口,其他人可以通过某种途径(可以是http链接,或者是基于socket的RPC调用)访问这个方法来注册。就是说把这个操作封装到一个工程中去,然后暴露访问的方式,形成“服务”。要修改关于注册用户的业务方法只要改这个服务就好了,很好的解耦。这样有什么好处呢?
-
扩展方便:一旦哪天突然有一堆人要注册,假设这堆人仅仅只是注册而不做其他事情,注册这个功能压力很大,而原有的一台部署了注册服务的服务器已经承受不了这么高的并发,这时候就可以单独集群部署这个注册服务,提供多几台服务器提供注册服务。
-
语言通用:实现这个服务的可以试任何语音,只要提供的接口通用就可以了,比如PHP擅长处理逻辑、Ruby语言擅长高并发、java擅长大数据等那我可以再比如某些业务逻辑很复杂的服务中使用PHP,在某些并发很高的服务中使用Ruby。
-
新人友好:新人进公司的时候他无需了解整个项目的架构是怎样的,比如你进阿里了,你想要熟练整个淘宝的架构你会累死,而这种SOA思想开发的项目由于是服务形式的,比方把你分到购物车组,那你只需要了解购物车的功能就好了。
-
发版方便:比方说你是淘宝购物车项目组的,你的项目改了一些东西要发版(发布生产),如果你是传统项目测试可能怕你改动到了其他的东西影响到了其他的功能(虽然你很确信没改动到,但万一呢?)不得不对淘宝整体的功能都做一遍测试,累死人,而这种形式的测试只需要测试你的购物车的功能,so easy。退一步说,万一你改的代码有问题测试没测出来,那也是影响购物车的功能,用户下单支付不影响。
说完了好处下面来说说坏处
-
问题排查不便:比方用户买东西的时候出现了一个报错,很难直接定位到问题出在哪个环节,可能是订单组的代码有问题,也可能是支付组的代码有问题。
-
沟通不便:如果你们在大公司待过的话就会明白,用户组,订单组,购物车组,支付组等等是分别属于不同的领导管理,出了问题沟通起来很麻烦,甚至你都不知道找谁沟通,也能以前跟你沟通的人后来离职了等等的问题。
-
性能问题:相对于传统项目的直觉调用,SOA中不管你是使用RPC还是什么HTTP等技术调用,肯定会有性能的损耗,因为网络通信是需要时间的。
-
关系混乱:当服务越来越多,调用方也越来越多的时候,它们之间的关系就变得非常混乱。
-
运维难度:随着服务的增多,系统架构会越发复杂,这就给运维层面带来了挑战。
-
数据一致性问题:单体项目因为数据都在同一个数据库里面,不需要过多的关注分布式事务等问题,SOA就需要关心了。
整体而言SOA肯定是利大于弊的,虽然缺点很明显,但是基本都是可以克服的,问题排查不便那就对花点时间差呗,沟通不便就找上级领导多沟通呗,性能问题用内网什么的也能降低到很少,关系乱就可以用服务治理。相对而言好处部分基本上是不可能克服的,比如非SOA项目扩展基本很难,全部的代码丢到一个项目里面类似淘宝这种新人可能看三年五年也看不懂。
就是当服务越来越多,调用方也越来越多的时候,它们之间的关系就变得非常混乱,需要对这些关系进行管理。举例,还是上面的例子,假如我有一个用户服务,一开始有调用方1和调用方2来使用这个服务,后来越来越多,将近上百个调用方,这个时候作为服务方,它只知道提供服务,却不知道具体为谁提供了服务。而对于开发者来说,知道这N多调用方和N多服务方之间的关系是非常重要的。所以这个时候就需要能进行服务治理的框架,比如dubbo+zookeeper,比如SpringCloud,有了服务治理功能,我们就能清晰地看到服务被谁谁谁调用,谁谁谁调用了哪些服务,哪些服务是热点服务需要配置服务器集群,而对这个服务集群的负载均衡也是服务治理可以完成的重要功能之一。
1.2 总结
实际上SOA只是一种架构设计模式,而SOAP、REST、RPC就是根据这种设计模式构建出来的规范,其中SOAP通俗理解就是http+xml的形式,REST就是http+json的形式,RPC是基于socket的形式。CXF就是典型的SOAP/REST框架,dubbo就是典型的RPC框架,而SpringCloud就是遵守REST规范的生态系统。
2:SpringCloud
简单来说,Spring Cloud是一个微服务框架的规范,注意,只是规范,他不是任何具体的框架。我们知道java大佬最喜欢的做法就是自己制定规范,然后别人基于我这个规范来做实现。那么这个规范里面有什么呢,它规定大概要有以下几种功能。
-
服务的注册与发现
-
负载均衡
-
服务熔断和限流
-
智能路由
-
控制总线
-
链路监控
-
…
刚好,这个时候有一个框架集合几乎能满足上面所有的需求,他就是Spring Cloud Netflix。当然,Spring Cloud的实现产品不止这一个,还有最近由阿里新起的Spring Cloud Alibaba等。目前国内主流的是Spring Cloud Netflix。也是本文介绍的主角。
2.1:什么是Spring Cloud Netflix
在介绍Spring Cloud Netflix之前,可以先了解下Netfix公司。因为Spring Cloud Netflix即是这家公司用的一个框架,把它开源出来了而已
Netflix是什么,与Spring Cloud有什么关系
1、首先,Netflix是一家做视频的网站,可以这么说该网站上的美剧应该是最火的。 2、Netflix是一家没有CTO的公司,正是这样的组织架构能使产品与技术无缝的沟通,从而能快速迭代出更优秀的产品。在当时软件敏捷开发中,Netflix的更新速度不亚于当年的微信后台变更,虽然微信比Netflix迟发展,但是当年微信的灰度发布和敏捷开发应该算是业界最猛的。 3、Netflix由于做视频的原因,访问量非常的大,从而促使其技术快速的发展在背后支撑着,也正是如此,Netflix开始把整体的系统往微服务上迁移。 4、Netflix的微服务做的不是最早的,但是确是最大规模的在生产级别微服务的尝试。也正是这种大规模的生产级别尝试,在服务器运维上依托AWS云。当然AWS云同样受益于Netflix的大规模业务不断的壮大。 5、Netflix的微服务大规模的应用,在技术上毫无保留的把一整套微服务架构核心技术栈开源了出来,叫做Netflix OSS,也正是如此,在技术上依靠开源社区的力量不断的壮大。 6、Spring Cloud是构建微服务的核心,而Spring Cloud是基于Spring Boot来开发的。 7、Pivotal在Netflix开源的一整套核心技术产品线的同时,做了一系列的封装,就变成了Spring Cloud;虽然Spring Cloud到现在为止不只有Netflix提供的方案可以集成,还有很多方案,但Netflix是最成熟的。 1234567
那么Spring Cloud Netflix有哪些组件呢?
-
eureka (提供服务注册与发现功能)
-
ribbon(提供负载均衡功能)
-
Feign(整合了ribbon和Hystrix,具有负载均衡和熔断限流等功能)
-
Hystrix (提供了熔断限流,合并请求等功能)
-
Zuul (提供了智能路由的功能)
-
Hystrix Dashboard (提供了服务监控的功能,提供了数据监控和友好的图形化界面)
-
Hystrix Turbine (Hystrix Turbine将每个服务Hystrix Dashboard数据进行了整合。也是监控系统的功能)
-
spring cloud config (提供了统一配置的功能)
-
Spring Cloud Bus (提供了配置实时更新的功能)
-
…
需要注意的是这些组件并不是一体化的,比如你完全可以用携程的Apollo来替换spring cloud config。也可以用NCOS或者Zookeeper来替换eureka.
2.2:Spring Cloud和Spring boot的关系
与其说他们有什么关系,不如说他们就没有什么关系。只是现在微服务当道,而实现一个服务最快的办法就是用spring boot。不然你还要自己搭项目自己找jar包自己搞配置,还有兼容性等情况。那你的服务化进程注定是缓慢的。所以他们之间是没有关系的,只是因为微服务所需要的小应用很多,而spring boot恰恰又是实现小应用最快的方式。
2.3:Spring Cloud和dubbo的关系
dubbo是阿里搞得一套框架,是基于RPC调用的,而Spring Cloud Netflix是基于HTTP的,所以效率上应该dubbo更快(如果你不能理解什么是RPC,当我没说,反正dubbo更快就是了)。但是dubbo的组件不是很齐全,他的很多功能比如服务注册与发现你需要借助于类似zookeeper等组件才能实现,而Spring Cloud Netflix则是提供了一站式解决方案。从使用广度来说,在国内几年前dubbo的使用人数远多于Spring Cloud的,但是近来Spring Cloud慢慢的有了后来居上的趋势。
3: 模拟微服务场景
3.1:创建项目名china-service-provider
创建pom文件需要webmysql,mybatis,jdbc启动项
<?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>2.0.6.RELEASE</version> <relativePath/> <!-- lookup parent from repository --> </parent> <groupId>com.chinasoft.service</groupId> <artifactId>china-service-provider</artifactId> <version>0.0.1-SNAPSHOT</version> <name>china-service-provider</name> <description>Demo project for Spring Boot</description> <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-jdbc</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.mybatis.spring.boot</groupId> <artifactId>mybatis-spring-boot-starter</artifactId> <version>2.1.2</version> </dependency> <!--domain sort的依赖--> <dependency> <groupId>org.springframework.data</groupId> <artifactId>spring-data-commons</artifactId> <version>2.1.6.RELEASE</version> </dependency> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <scope>runtime</scope> </dependency> <dependency> <groupId>org.springfra