什么是微服务?为什么使用微服务?
在讲解SpringCloud之前 我们必须要谈论一个重要的内容,到底什么是微服务,想必大家在网上查询之后有海量的答案让人眼花缭乱,所以在这里我们就先一起探讨一下微服务到底是什么神奇的东西.
可能大多数的java程序猿做的项目都是xxxx管理系统,xxxxCRM系统,这些项目只是针对某一个公司或者部门开发,用户量也不会很大(我们家楼下的理发店都有一个管理系统 用户只有店长和几个洗发的韩潮小哥),千篇一律的CRUD逐渐的让大家觉得甚是无聊,偶尔可能接几个毕设来贴补家用,我相信所有的程序猿都听说过微服务,但是不是每一个人都接触过微服务,即使没有接触过利用空闲的时间来学习学习也是不错的.
话不多说切入正题,单体架构的项目相信大家在学习或者工作的阶段都是开发过的,当大家完成了一个单体架构后想必也会有几分成就感,但是不要让一时的成就感蒙蔽了你的双眼,要知道单体架构的问题远比你想象的多.
- 单体架构的几个重要问题
- 复杂度的提升: 你永远不知道客户的需求有多么奇葩,你也永远不会知道你的上一任会给你留下多少的技术债务,一个类中写几千几万行代码的时候,我们就有一种想kill人的冲动,想重构代码又害怕会影响整个项目,只能硬着头皮继续往下写,这是一个恶性循环,我们只能祈祷不要做压死骆驼的最后一根稻草.
- 项目部署: 不是所有的团队都有运维人员,基本上小公司的开发人员不光要开发代码还要部署项目,我承认这对程序员来说是一件好事,可以学习到更多的东西,但是当代码量越发庞大,项目的部署就会越来越慢,朋友公司每天只能有一次部署机会,因为部署一次需要5个小时,第一次代码没有写好那么只能加班了.
- 技术障碍: 随着现在技术的更新越来越快,很多老板听说了一个什么新的技术好像不错就想让自己的员工来尝试一下,技术选型应该是我们开发人员集体研讨的结果,但是若没有很好的前瞻性,在未来的日子里想要改造项目那简直就是噩梦,这时候我们的心声是重新写一个吧,肯定比改造要快很多
- 问题排查: 高内聚低耦合是我们常说的话,但是原本想遵循这个原则但是代码写着写着就变了味道,到后来想着只要能完成需求就行了,这个时候面对如此高复杂度的项目排查问题就好比上演了一部侦探破案的悬疑剧.我承认改bug是自我提升的一个方式,但是谁也不想天天改那些诡异的bug.
单体结构虽说有很多的问题,但是对于业务不是很复杂,用户量没有过高要求的简单小项目还是建议使用的,若是庞大复杂的业务逻辑以及海量的用户群体,那么微服务可以很好的解决以上问题.
到底什么是微服务? 通俗的讲就是把原来单体结构的项目拆分成一个一个的独立模块,单独运行
这就好比是搭积木,每一块积木是一个模块,各个模块连在一起是整个项目
微服务架构是一种将单应用程序作为一套小型服务开发的方法，每种应用程序都在其自己的进程中运行，并与轻量级机制进行通信。这些服务是围绕业务功能构建的，可以通过全自动部署机制进行独立部署。这些服务的集中化管理已经是最少的，它们可以用不同的编程语言编写，并使用不同的数据存储技术。(这句话是我copy的 :))
既然是独立的各个模块,那么开发人员更多的需要专注于自己模块的业务逻辑以及代码质量和问题(内心戏:终于不用看别人糟糕的代码了)
什么是SpringCloud
既然已经知道了什么是微服务,那么如何搭建微服务就是一个重要的课题了,各个服务之间如何协作,如何传递消息,如何共享数据等等等等......
这些都是我们需要考虑的东西,此时我们内心是崩溃的,为什么微服务还要考虑那么多的东西,但是朋友,千里之行始于足下,前期的准备越充分,对于以后的开发就越方便,万幸我们生活在了这个时代,你能想到的事情SpringCloud帮助你考虑到了,你想不到的事情SpringCloud也帮你考虑到了,SpringCloud就是各个微服务的管理者相当于大佬的存在
这个大佬不一般 , Spring并没有重复制造轮子，它只是将目前各家公司开发的比较成熟、经得起实际考验的服务框架组合起来，通过Spring Boot风格进行再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包
对于SpringCloud的基本学习也是极其简单的,不会有很高的学习曲线 ,总之SpringCloud把你能干的不能干的都干了,就是想让你安安静静的开发自己的功能,其他的事情都交给SpringCloud处理就好了
学习SpringCloud要学习什么?
这个大佬的功能有很多,不是所有的功能都能够用在自己的项目之中的,但是最最主要的东西我们还是需要好好的了解一下,暂且不考虑它的内部到底怎么实现,对于刚上手的你来说,会用才是最最实在的.
下面我来先简单说一下SpringCloud的核心的几个组件
- 注册中心Eureka
Eureka [ju?ri:k?] 读法:尤瑞卡 翻译成中文的话 意思就好比你从很久不穿的衣服里找到了100块钱后说的话差不多(为什么我要强调一下读音,说实话我们程序员能看懂英文文档,但是不一定能读,尤其是面试的时候很多名词说出来自己都觉得不好意思)
举个例子帮助大家理解注册中心的作用 张三向李四打电话这么一个过程如图所示
但是实际上一通电话的过程并没有这么简单 我们的电话信号并不是直接连接到另一个人的 而是需要经过中间商(基站) 移动,联通或电信
如果把张三和李四好比两个微服务 那么eureka就是这个基站 eureka提供的服务功能包括服务的注册、发现、熔断、负载、降级等,当服务有很多个的时候我们就通过服务中心来去请求其他服务
那么为什么非要用一个服务中心呢 微服务之间直接请求不好吗? 就像打电话一样 如果我们不通过基站 而是直接给李四发送信号 若李四关机或者正在通话等等意外情况 张三无法与李四联系到 那么张三永远得不到反馈.而有了这个基站 就会有客服小姐姐的声音 "对不起您所拨打的电话已关机" "请不要挂机,您所拨打的电话正在通话中". eureka服务中心就像这个客服一样当服务发生了各种各样的问题,eureka也可以做出不同的处理,处理方式就可以任由开发人员来做了.
- Ribbon和Feign
- ribbon [?r?b?n] 翻译成中文是"色带"的意思
- feign [fe?n] 中文佯装
在微服务架构中，业务都会被拆分成一个独立的服务，服务与服务的通讯是基于http restful的.Spring cloud有两种服务调用方式，一种是ribbon+restTemplate，另一种是feign
为什么我把这两个东西放在一起 官网上有这么一句话
Ribbon is a client side load balancer which gives you a lot of control over the behaviour of HTTP and TCP clients. Feign already uses Ribbon
翻译过来是这样的
ribbon是一个负载均衡客户端，可以很好的控制http和tcp的一些行为。Feign默认集成了ribbon。
为了简化学习曲线 我们可以更加专注的学习Feign 那么这两个组件到底是干什么的?
划重点 负载均衡 想必这个词大家肯定不陌生,总是能听到负载均衡这4个字 那么到底什么才是负载均衡, 我再给大家举一个例子 上学期间我们肯定都有过在食堂排队打饭的经历
如果食堂只有一个窗口的话那么大家就只能一个一个的排队去打饭 这样会给这个食堂大妈造成很大的压力 无法和门口看门大爷打情骂俏了 甚至食堂大妈会牺牲在工作岗位,那么排队的同学就没有办法吃饭了我们的项目也是一样 如果大量用户去访问服务,那么服务的压力会很大,很有可能承受不住压力导致挂掉.
那么如何解决这个问题
食堂我们可以多添加几个窗口
如图所示你会发现我多添加了两个窗口 但是第一个窗口排队的人还是很多 第三个窗口都没有人排队 这就反应了一个问题 虽说窗口增多了 但是排队的人都在低头玩手机 全然不知道窗口已经增加了 如果是这个样子的话那么就会造成资源的浪费 所以我还需要一个管理员 帮助学生排队保证他们能以最快的速度吃上饭
Feign默认集成了Ribbon，并和Eureka结合，默认实现了负载均衡的效果图中的管理员的角色就类似Feign 但是Feign能做的远远比这多很多
用比较官方的话来说
Feign是spring cloud中服务消费端的调用框架,使得 Java HTTP 客户端编写更方便
在spring Cloud Netflix栈中，各个微服务都是以HTTP接口的形式暴露自身服务的，因此在调用远程服务时就必须使用HTTP客户端。我们可以使用JDK原生的URLConnection、Apache的Http Client、Netty的异步HTTP Client, Spring的RestTemplate。但是，用起来最方便、最优雅的还是要属Feign了。
Feign是一种声明式、模板化的HTTP客户端。在Spring Cloud中使用Feign, 我们可以做到使用HTTP请求远程服务时能与调用本地方法一样的编码体验，开发者完全感知不到这是远程方法，更感知不到这是个HTTP请求。
个人总结而言 Feign类似一个助手帮助我们去调用其他服务的接口,使用和配置都十分的简单,极易上手操作
- Hystrix断路器
断路器是一个很好理解的概念 想必在单体结构中我们曾经发生这样的事情 若某一个功能模块发生了问题,那么可能会导致工程报错出现问题,同样在微服务中我们也不能保证每一个微服务都是100%好用的,若另一个服务要获取出问题的服务里的内容,那肯定也会出现问题,很有可能多个服务受到连锁反应,项目瘫痪. 这不是我们想看到的结果,所以断路器是一个很好的解决方式,它就像是森林大火的隔离带,当某一个微服务出现了问题,那么可以用断路器将其隔离,后续的处理就可以由我们开发人员自己来做了.
- Zuul
Zuul是SpringCloud中的一个十分重要的角色, 首先我们需要明确一个概念 什么是路由,
通俗的讲路由就是一个路径的解析，根据客户端提交的路径，将请求解析到相应的控制器上,好比打电话 输入手机号拨打出去,就能找到你想找的人
路由是微服务架构中必须（integral ）的一部分，比如，“/” 可能映射到你的WEB程序上，”/api/users “可能映射到你的用户服务上，“/api/shop”可能映射到你的商品服务商。
Zuul就是帮助我们处理路由的角色.
Zuul的主要功能是路由转发和过滤器. 转发和过滤器这个概念我就不再墨迹了,相信大家都明白是什么意思.
- Spring Cloud Config
如此见名知意的命名,大家应该能猜到Spring Cloud Config的作用,没错它就是SpringCloud的配置
在分布式系统中，由于服务数量巨多，为了方便服务配置文件统一管理，实时更新，所以需要分布式配置中心组件。在Spring Cloud中，有分布式配置中心组件spring cloud config ，它支持配置服务放在配置服务的内存中（即本地），也支持放在远程Git/SVN仓库中
能够统一的管理配置文件对于开发人员来说是莫大的福音,若条件允许可以交给运维老哥帮我们完成(若是小公司没有运维人员,那么还是要自己干的).
- Spring Cloud Bus
上面我简单的介绍了一下SpringCloud Config 但是有这么一个问题 统一配置了文件之后,我们如何通知到各个微服务呢? 我们总不可能每一个微服务都重新启动一下吧,这时我们所学习的设计模式就起到了作用 发布订阅模式(若不知道发布订阅模式可以自行查询一下) 让所有为服务来订阅这个事件，当这个事件发生改变了，就可以通知所有微服务去更新它们的内存中的配置信息.这时Bus消息总线就能解决，你只需要在springcloud Config Server端发出refresh，就可以触发所有微服务更新了.
- Sleuth + Zipkin
在微服务中,我们需要根据具体的业务来规划哪些功能作为一个服务,某些功能可能会调用多个微服务,这就组成了一个关系复杂的结构,服务的数量越多就越不好监控管理这些服务,所以为了方便开发人员管理 SpringCloud提供了Sleuth
Spring Cloud Sleuth 主要功能就是在分布式系统中提供追踪解决方案，并且兼容支持了 zipkin，你只需要在pom文件中引入相应的依赖即可
最最贴心的是提供了可视化链路监控 更加方便我们的操作
<font color = "red">以上总结的内容都是我们学习的重点内容,当然并不是其他的东西就不重要 以下还有很多内容</font>
- Spring Cloud Security
基于spring security的安全工具包，为你的应用程序添加安全控制。这个小弟很牛鼻专门负责整个帮派的安全问题，设置不同的门派访问特定的资源，不能把秘籍葵花宝典泄漏了。
- Spring Cloud Sleuth
日志收集工具包，封装了Dapper和log-based追踪以及Zipkin和HTrace操作，为SpringCloud应用实现了一种分布式追踪解决方案。
- Spring Cloud Data Flow
- Data flow 是一个用于开发和执行大范围数据处理其模式包括ETL，批量运算和持续运算的统一编程模型和托管服务。
- 对于在现代运行环境中可组合的微服务程序来说，Spring Cloud data flow是一个原生云可编配的服务。使用Spring Cloud data flow，开发者可以为像数据抽取，实时分析，和数据导入/导出这种常见用例创建和编配数据通道 （data pipelines）。
- Spring Cloud data flow 是基于原生云对 spring XD的重新设计，该项目目标是简化大数据应用的开发。Spring XD 的流处理和批处理模块的重构分别是基于 Spring Boot的stream 和 task/batch 的微服务程序。这些程序现在都是自动部署单元而且他们原生的支持像 Cloud Foundry、Apache YARN、Apache Mesos和Kubernetes 等现代运行环境。
- Spring Cloud data flow 为基于微服务的分布式流处理和批处理数据通道提供了一系列模型和最佳实践。
- Spring Cloud Stream
Spring Cloud Stream是创建消息驱动微服务应用的框架。Spring Cloud Stream是基于Spring Boot创建，用来建立单独的／工业级spring应用，使用spring integration提供与消息代理之间的连接。数据流操作开发包，封装了与Redis,Rabbit、Kafka等发送接收消息。
一个业务会牵扯到多个任务，任务之间是通过事件触发的，这就是Spring Cloud stream要干的事了
- Spring Cloud Task
Spring Cloud Task 主要解决短命微服务的任务管理，任务调度的工作，比如说某些定时任务晚上就跑一次，或者某项数据分析临时就跑几次。
- Spring Cloud Zookeeper
ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等。ZooKeeper的目标就是封装好复杂易出错的关键服务，将简单易用的接口和性能高效、功能稳定的系统提供给用户。
操作Zookeeper的工具包，用于使用zookeeper方式的服务发现和配置管理，抱了Zookeeper的大腿。
- Spring Cloud Connectors
Spring Cloud Connectors 简化了连接到服务的过程和从云平台获取操作的过程，有很强的扩展性，可以利用Spring Cloud Connectors来构建你自己的云平台。
便于云端应用程序在各种PaaS平台连接到后端，如：数据库和消息代理服务。
- Spring Cloud Starters
Spring Boot式的启动项目，为Spring Cloud提供开箱即用的依赖管理。
- Spring Cloud CLI
基于 Spring Boot CLI，可以让你以命令行方式快速建立云组件。
如何学习SpringCloud
前面总结了要学习那些内容,当然我们最最关心的还是代码怎么写,这里我先分享一下我的经验,希望对大家有所帮助
对于初学者来说 首先一定要知道自己在干什么,盲目的学习是没有效果的,既然我们已经知道了要学习什么就要知道,一步一步的完成它,再去熟练它.
其次要敢于犯错,写代码不要想着一次就成功,学习阶段的错误犯得越多,那么对自己的收获就越大,寻找问题的本质,学会查看日志,逐一排查错误. 千万不要犯错了就马上对照别人的代码看看自己写的哪里和别人不一样,这样所说你达到了预期的效果,但是并没有真正的学会它
本文就是自己在学习SpringCloud的总结,写了这个总结后,发现对SpringCloud的使用更加清晰.
本文暂时没有评论，来添加一个吧(●'◡'●)