SpringBoot揭秘:快速构建微服务体系.html.pdf
《SpringBoot揭秘:快速构建微服务体系.html.pdf》由会员分享,可在线阅读,更多相关《SpringBoot揭秘:快速构建微服务体系.html.pdf(29页珍藏版)》请在三一文库上搜索。
1、推荐序1 2015年技术圈最火的名词大概就是微服务了。国内外的互联网技术会议上,但凡分享题目中包含“MicroService”,不论内容质量如何,一定人山人海、摩肩接踵。 追本溯源,服务化的架构思想十年前就是软件架构的标准范式。淘宝和阿里在2007年左右就开始奠定了大规模服务化架构的基础,经过几代架构师的努力,有了今天承载双十一规模的商业操作系统。 这中间诞生的很多优秀的Java中间件也成为开源界备受追崇的范例。 但是对于很多中小企业而言,SpringBoot会是另一个性价比极高的选择。福强的这本书出现得恰逢其时,既有体系化的理论又不乏有价值的实践。对于想了解微服务和SpringBoot的架构
2、师而言,是难 得的修炼秘籍。 南天(本名是庄卓然) 阿里巴巴资深总监 推荐序2 多年前,第一次见福强,就知道他在写书,那时就是关于Spring的书籍。等到出书后,我翻看之下,发现福强写得非常实用。 时隔若干年,福强又来信告知有新作问世,这是他经历几年的大型网站实践之后,在创业阶段写的书。在这个阶段还能坚持写作的人非常少,足以说明他对技术的执着和坚持。有了成熟大型网站和创 业阶段的实践经验,本书不仅是SpringBoot的指南,还是各种实战经验的提炼和总结。福强不仅在Java,在Scala、Golang方面都有颇深的理解,这种跨语言方面对技术的融会贯通也为整个构建过程起着 催化剂的作用。福强这次
3、给大家带来的这本书,从不同角度对微服务这一热门话题进行了介绍和探讨,同时加入了自己多年的实践经验,值得一读。 Eric(中文名是王齐) 平安好医生CTO 序言 随着微服务(Micro Service)理念的盛行,一个流行的概念也随之诞生微框架(Micro Framework),而其中最耀眼的,当属SpringBoot。 虽然Dropwizard是公认的最早的微框架,但SpringBoot“青出于蓝而胜于蓝”,背靠Spring框架衍生出来的整个生态体系,无论是从“出身”,还是社区的支撑上,SpringBoot都是微框架选型的不 二之选。 实际上,SpringBoot并非单单一个微框架的概念就可以
4、概括,笔者认为将SpringBoot看作一种最佳实践会更为贴切:一种Spring框架及其社区对“约定优先于配置”(Convention Over Configuration)理念的最佳实践。 温故而知新,笔者将通过本书带领大家回顾Spring框架的历史,进而引领大家探索SpringBoot框架的来龙去脉,最终引领大家去探索基于SpringBoot的微服务实践之路。希望各位能够享受这段文字 旅程并有所收获。 前言 为什么写这本书 忘了是2015年的哪一天,只记得几个朋友跟友商的其他几个做技术的朋友吃饭,并简单做下技术交流。席间,友商的几位朋友对SpringBoot框架实施微服务很感兴趣,交谈甚欢
5、之际,我无意间开玩笑 说:“是不是该考虑写一本SpringBoot的书?”钟伦甫(原淘宝聚石)同学随口一句,“你倒是写啊!”,得,以行践言吧,谁让你把话说出去了呢? 当然,朋友的“热切期盼”只是其一,微服务盛行也是本书写作的一个契机,希望本书成为国内第一本微服务相关的原创图书,借此跟大家分享我对微服务的浅薄理解,并围绕SpringBoot微框架打造 一套微服务体系可能的探索方向,权作抛砖引玉。如果不同的思想可以借此激荡和碰撞形成更多共鸣,则吾之幸甚。 因工作繁忙,只能抽取零碎时间躬耕于晨曦和月光之下,经点滴积累,才终成此书,希望大家阅读愉快。 本书的主要内容和特色 本书以介绍微服务的基本概念开
6、篇,逐步引出Java平台下打造微服务的利器SpringBoot微框架。书中从SpringBoot微框架的“出身”开始,循序渐进,一步步为大家剖析SpringBoot微框架的设 计理念和原理,并对框架的重点功能和模块进行了逐一讲解。 当然,这还只是“前戏”,本书最精彩的部分在于,在大家对SpringBoot微框架已经有了基本的认识之后,我们将一起探索如何基于SpringBoot微框架打造一套完备的微服务体系。因为如果没有平台 化体系化的基础支撑,空谈微服务将无太大意义。 SpringBoot微框架依托Java平台和Spring框架,拥有良好的可扩展性和可定制性,为了说明这一点,我们单独开辟了一章
7、内容,为大家介绍如何使用Scala和SpringBoot微框架来开发和交付相应的微 服务,并且围绕Scala和SpringBoot如何打造相应的工具,技术产品等支持来提高相应微服务的交付效率。 最后我会与大家一起对SpringBoot微框架的相关内容进行回顾和展望,以期温故而知新。 本书总体上可以总结为三个关键词,“框架、体系、生态”,三者循序渐进,相辅相成,在使用SpringBoot微框架打造自己特色的微服务体系和技术生态之时,希望大家记住这三个关键词。 本书面向的读者 本书希望面向的读者当然是那些对SpringBoot微框架感兴趣的同学,如果你想了解SpringBoot微框架,并且尝试进一
8、步深入定制该框架以满足自己团队和公司的需要,也希望会对你有所启发。 除此之外还包括: Java平台上的广大研发同学,可以借此书了解业界微服务相关的最新动态。 其他平台上的广大研发同学,可借此书“管中窥豹”,了解微服务的一般体系和生态建设,对比并引入自身的技术和微服务体系建设之中。 脱离技术一线已久的技术负责人。 如何阅读本书 本书采用循序渐进的形式编写,所以顺序阅读是推荐的阅读方式。 勘误和资源 鉴于一家之言且编撰仓促,难免会有所纰漏,观点有失偏颇,所以,我在github网站上专门新建了一个issue项目(https:/ 阅读此书之后发现有哪些错误和疑问,或者改进建议,可以在此项目上新建iss
9、ue来表达自己的观点和建议。如果时间不充裕,我会适时地选择性给予答复,当然,更希望大家可以通过issue展开讨论,互相 切磋和解答疑问。 致谢 除了最初的一句戏言,钟伦甫同学也是本书的第一位读者,帮助审稿并提出很多建议,所以,本书得以出版,第一需要感谢的就是钟伦甫同学。 其次,我要感谢华章出版社的杨福川和李艺,福川兄在接到我的出版意向之后,快速地跟进和落实,在本书初稿编写完成时马上着手出版,诸位得以在2016年上半年就手捧此书,皆需感谢福川兄的重 点关注和推进。 最后要感谢我的父母,感谢他们把我带到这个世界上并让我做自己想做和要做的事情。 第1章 了解微服务 SpringBoot是一个可使用J
10、ava构建微服务的微框架,所以在了解SpringBoot之前,我们需要先了解什么是微服务。 1.1 什么是微服务 微服务(Microservice)虽然是当下刚兴起的比较流行的新名词,但本质上来说,微服务并非什么新的概念。实际上,很多SOA实施成熟度比较好的企业,已经在使用和实施微服务了。只不过,它们 只是在闷声发大财,并不介意是否有一个比较时髦的名词来明确表述SOA的这个发展演化趋势罢了。 微服务其实就是服务化思路的一种最佳实践方向,遵循SOA的思路,各个企业在服务化治理的道路上走的时间长了,踩的坑多了,整个软件交付链路上各个环节的基础设施逐渐成熟了,微服务自然而 然就诞生了。 当然,之所以
11、叫微服务,是与之前的服务化思路和实践相比较而来的。早些年的服务实现和实施思路是将很多功能从开发到交付都打包成一个很大的服务单元(一般称为Monolith),而微服务实现和 实施思路则更强调功能趋向单一,服务单元小型化和微型化。如果用“茶壶煮饺子”来打比方的话,原来我们是在一个茶壶里煮很多个饺子,现在(微服务化之后)则基本上是在一个茶壶煮一个饺子,而 这些饺子就是服务的功能,茶壶则是将这些服务功能打包交付的服务单元,如图1-1所示。 图1-1 论茶壶里煮“饺子”的不同形式 所以,从思路和理念上来讲,微服务就是要倡导大家尽量将功能进行拆分,将服务粒度做小,使之可以独立承担对外服务的职责,沿着这个思
12、路开发和交付的软件服务实体就叫作“微服务”,而围绕 着这个思路和理念构建的一系列基础设施和指导思想,笔者将它称为“微服务体系”。 1.2 微服务因何而生 微服务的概念我们应该大体了解了,那么微服务又是怎么来的?原来将很多功能打包为一个很大的服务单元进行交付的做法不能满足需求吗? 实际上,并非原来“大一统”(Monolith)的服务化实践不能满足要求,也不是不好,只是,它有自己存在的合理场景。对于Monolith服务来说,如果团队不大,软件复杂度不高,那么,使用 Monolith的形式进行服务化治理是比较合适的,而且,这种方式对运维和各种基础设施的要求也不高。 但是,随着软件系统的复杂度持续飙升
13、,软件交付的效率要求更高,投入的人力以及各项资源越来越多,基于Monolith的服务化思路就开始“捉襟见肘”。 在开发阶段,如果我们遵循Monolith的服务化理念,通常会将所有功能的实现都统一归到一个开发项目下,但随着功能的膨胀,这些功能一定会分发给不同的研发人员进行开发,造成的后果就是,大 家在提交代码的时候频繁冲突并需要解决这些冲突,单一的开发项目成为了开发期间所有人的工作瓶颈。 为了减轻这种苦恼,我们自然会将项目按照要开发的功能拆分为不同的项目,从而负责不同功能的研发人员就可以在自己的代码项目上进行开发,从而解决了大家无法在开发阶段并行开发的苦恼。 到了软件交付阶段,如果我们遵循Mon
14、olith的服务化理念,那么,我们一定是将所有这些开发阶段并行开发的项目集合到一起进行交付,这就涉及服务化早期实践中比较有名的“火车模型”,即交付 的服务就像一辆火车,而这个服务相关的所有功能对应的项目成果,就是要装上火车车厢的一件件货物,交付的列车只有等到所有项目都开发测试完成后才可以装车出发,完成整个服务的交付。很显然, 只要有一个车厢没有准备好货物(即功能项目未开发测试完成),火车就不能发车,服务就不能交付,这大大降低了服务的交付效率。如果每个功能项目可以各自独立交付,那么就不需要都等同一辆火 车,各自出发就可以了。顺着这个思路,自然而然地,大家逐渐各自独立,每一个功能或者少数相近的功能
15、作为单一项目开发完成后将作为一个独立的服务单元进行交付,从而在服务交付阶段,大家也能 够并行不悖,各自演化而不受影响。 所以,随着服务和系统的复杂度逐渐飙升,为了能够在整个软件的交付链路上高效扩展,将独立的功能和服务单元进行拆分,从而形成一个一个的微服务是自然而然发生的事情。这就像打不同的战役 一样,在双方兵力不多、战场复杂度不高的情况下,Monolith的统一指挥调度方式是合适的;而一旦要打大的战役(类似于系统复杂度提升),双方一定会投入大量的兵力(软件研发团队的规模增长), 如果还是在狭小甚至固定的战场上进行厮杀,显然施展不开!所以,小战役有小战役的打法,大战役有大战役的战法,而微服务实际
16、上就是一种帮助扩展组织能力、提升团队效率的应对“大战役”的方 法,它帮助我们从软件开发到交付,进而到团队和组织层面多方位进行扩展。 总的来说,一方面微服务可以帮助我们应对飙升的系统复杂度;另一个方面,微服务可以帮助我们进行更大范围的扩展,从开发阶段项目并行开发的扩展,到交付阶段并行交付的扩展,再到相应的组 织结构和组织能力的扩展,皆因微服务而受惠。 1.3 微服务会带来哪些好处 显然,随着系统复杂度的提升,以及对系统扩展性的要求越来越高,微服务化是一个很好的方向,但除此之外,微服务还会给我们带来哪些好处? 1.4 微服务会带来哪些挑战 微服务给我们带来的并非只有好处,还有相应的一些挑战。 服务
17、“微”化之后,一个显著的特点就是服务的数量增多了。如果将软件开发和交付也作为一种生产模式看待,那么数量众多的微服务实际上就类似于传统生产线上的产品,而在传统生产模型下,为 了能够高效地生产大量产品,通常采用的就是标准化生产。 比如在汽车产业,在福特T型车没有出来之前,大多汽车企业的生产效率都不高,而福特在引入标准化生产线之后,福特T型车得以大量生产并以低成本优势快速普及。 在其他行业也是同样的道理,个性化生产虽然会深得个别用户的喜欢,但生产成本通常也会很高,生产效率因为受限于个性化需求,也无法从“熟能生巧”中获益,所以,最终用户需要为生产成本和 效率付出更多的溢价才能获得最终产品。而相对于个性
18、化生产来说,标准化生产走的是另一条路,通过生产标准产品,使得整条生产链路可重复,从而提升了生产效率,可以为更广层面的用户提供大 量“物美价廉”的标准产品。 微服务的研发和交付其实就类似于产品的生产链路,而数量大这一特点则决定了,我们无法通过个性化的生产模式来支撑整个微服务的交付链路和研发体系,虽然微服务化之后,我们可以投入相应的 人力和团队对应各个微服务的开发和交付,可扩展性上绝对没有问题,但这不意味着现实情况下我们就能这样做,因为这些都涉及人力和资源成本,而这往往是受限的。所以,使用标准化的思路来开发和 交付微服务就变成了自然而然的选择: 通过标准化,我们可以重复使用开发阶段打造的一系列环境
19、和工具支持。 通过标准化,我们可以复用支持整个微服务交付链路的各项基础设施。 通过标准化,我们可以减少采购差异导致的成本上升,同时更加高效地利用硬件资源。 通过标准化,我们可以用标准的协议和格式来治理和维护数量庞大的微服务。 如果你还对使用标准化的思路来构建微服务体系存有疑惑,那么,不妨再结合微服务的多语言生态特性思考一番: 增加一种语言生态用于微服务的开发和交付,我们是否要围绕着这种语言生态和微服务的需求重新搭建一套研发/测试环境? 我们是否还要围绕着这种语言生态打造一系列的工具来提升日常开发的效率? 增加一种语言生态,我们是不是还要围绕这种语言生态搭建一套针对微服务的交付链路基础设施? 增
20、加一种语言生态,我们是否还要围绕它提供特定的硬件环境以及运维支撑工具和平台? 多语言生态虽然灵活度高了,不同语种和思路的团队成员也能够百花齐放了,但是不是也同样带来了以上一系列的成本? 所以,很多事情你能做,并不意味着你一定要做。适度的收缩语言生态的选择范围,并围绕主要的语言生态构建一套标准化的微服务交付体系,或许是更为合理的做法。 要实施高效可重复的标准化微服务生产,我们需要有类似传统行业生产线的基础设施。否则,高效可重复的开发和交付大量的微服务就无从谈起,所以,完备的微服务研发和交付体系基础设施建设就 成为了实施微服务的终极挑战。一个公司或者组织要很好地或者说成熟地实施微服务化战略,为交付
21、链路提供完备支撑的基础设施建设必不可少! 1.5 本章小结 在带领大家探索本书的主角SpringBoot微框架之前,本章首先为大家介绍了SpringBoot微框架服务的核心场景,即微服务。然后一起探索了微服务的概念以及由来,并探讨了微服务可以为我们带来哪 些好处,以及同时又为我们带来哪些挑战。 总的来说,微服务化虽然是当下流行的趋势,但并非任何场景都合适,我们还是要审慎地在“大一统”(Monolith)服务架构和微服务架构之间做出选择,而一旦确定选择了微服务化之路,那么,就 应该围绕团队和组织的主要语言生态以及微服务方向积极探索高效的微服务开发和交付模式。 SpringBoot微框架实际上就是
22、为Java语言生态而生的一种微服务最佳实践,在第2章中我们将从回顾SpringBoot的起源开始,逐步揭开SpringBoot微框架的神秘面纱。 第2章 饮水思源:回顾与探索Spring框架的本质 SpringBoot框架的命名关键在“Boot”上,或许Boot Spring更能说明这个微框架设计的初衷,也就是快速启动一个Spring应用! 所以,自始至终,SpringBoot框架都是为了能够帮助使用Spring框架的开发者快速高效地构建一个个基于Spring框架以及Spring生态体系的应用解决方案。要深刻理解SpringBoot框架,首先我们需 要深刻理解Spring框架,所以让我们先来读
23、读历史吧! 2.1 Spring框架的起源 虽然笔者在自己的上一本著作Spring揭秘中对Spring框架进行了十分详尽的介绍和剖析,但这里还是要再啰嗦几句。 Spring框架诞生于“黑暗”的EJB 1的时代(如果你没有听说过,恭喜你,说明你还年轻),那是一个J2EE规范统治的时代,基于各种容器和J2EE规范的软件解决方案是唯一的“正道”,沉重的研发模 式和生态让那个时代的开发者痛苦不堪。随着经典巨著Expert One-on-One J2EE Design and Development的诞生,重规范时代终于迎来了一线曙光,该书的作者Rod Johnson在书中阐述了轻量级 框架的研发理念,
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- SpringBoot 揭秘 快速 构建 微服 体系 html
链接地址:https://www.31doc.com/p-5518989.html