|
|
51CTO旗下网站
|
|
移动端

第2章 使用Spring Boot构建微服务

《Spring微服务实战》第2章使用Spring Boot构建微服务,Spring,本章将演示如何从这些角色的视角使用Spring Boot和Java设计和构建一组微服务。到本章结束时,读者将有一个可以打包并部署到云的服务。本节为大家介绍使用Spring Boot构建微服务。

作者:陈文辉 译来源:人民邮电出版社|2018-05-23 14:22

第2章 使用Spring Boot构建微服务

本章主要内容

学习微服务的关键特征

了解微服务是如何适应云架构的

将业务领域分解成一组微服务

使用Spring Boot实现简单的微服务

掌握基于微服务架构构建应用程序的视角

学习什么时候不应该使用微服务

软件开发的历史充斥着大型开发项目崩溃的故事,这些项目可能投资了数百万美元、集中了行业里众多的顶尖人才、消耗了开发人员成千上万的工时,但从未给客户交付任何有价值的东西,最终由于其复杂性和负担而轰然倒塌。

这些庞大的项目倾向于遵循大型传统的瀑布开发方法,坚持在项目开始时界定应用的所有需求和设计。这些项目的开发人员非常重视软件说明书的“正确性”,却很少能够满足新的业务需求,也很少能够重构并从开发初期的错误中重新思考和学习。

但现实情况是,软件开发并不是一个由定义和执行所组成的线性过程,而是一个演化过程,在开发团队真正明白手头的问题前,需要经历与客户沟通、向客户学习和向客户交付的数次迭代。

使用传统的瀑布方法所面临的挑战在于,许多时候,这些项目交付的软件制品的粒度具有以下特点。

紧耦合的——业务逻辑的调用发生在编程语言层面,而不是通过实现中立的协议(如SOAP和REST)。这大大增加了即使对应用程序组件进行小的修改也可能打破应用程序的其他部分并引入新漏洞的机会。

有漏洞的——大多数大型软件应用程序都在管理着不同类型的数据。例如,客户关系管理(CRM)应用程序可能会管理客户、销售和产品信息。在传统的模型里,这些数据位于相同的数据模型中并在同一个数据存储中保存。即使数据之间存在明显的界限,在绝大多数的情况下,来自一个领域的团队也很容易直接访问属于另一个团队的数据。这种对数据的轻松访问引入了隐藏的依赖关系,并让组件的内部数据结构的实现细节泄漏到整个应用程序中。即使对单个数据库表的更改也可能需要在整个应用程序中进行大量的代码更改和回归测试。

单体的——由于传统应用程序的大多数组件都存放在多个团队共享的单个代码库中,任何时候更改代码,整个应用程序都必须重新编译、重新运行并且需要通过一个完整的测试周期并重新部署。无论是新客户的需求还是修复错误,应用程序代码库的微小变化都将变得昂贵和耗时,并且几乎不可能及时实现大规模的变化。

基于微服务的架构采用不同的方法来交付功能。具体来说,基于微服务的架构具有以下特点。

有约束的——微服务具有范围有限的单一职责集。微服务遵循UNIX的理念,即应用程序是服务的集合,每个服务只做一件事,并只做好一件事。

松耦合的——基于微服务的应用程序是小型服务的集合,服务之间使用非专属调用协议(如HTTP和REST)通过非特定实现的接口彼此交互。与传统的应用程序架构相比,只要服务的接口没有改变,微服务的所有者可以更加自由地对服务进行修改。

抽象的——微服务完全拥有自己的数据结构和数据源。微服务所拥有的数据只能由该服务修改。可以锁定微服务数据的数据库访问控制,仅允许该服务访问它。

独立的——微服务应用程序中的每个微服务可以独立于应用程序中使用的其他服务进行编译和部署。这意味着,与依赖更重的单体应用程序相比,这样对变化进行隔离和测试更容易。

为什么这些微服务架构属性对基于云的开发很重要?基于云的应用程序通常有以下特点。

拥有庞大而多样化的用户群——不同的客户需要不同的功能,他们不想在开始使用这些功能之前等待漫长的应用程序发布周期。微服务允许功能快速交付,因为每个服务的范围很小,并通过一个定义明确的接口进行访问。

极高的运行时间要求——由于微服务的分散性,基于微服务的应用程序可以更容易地将故障和问题隔离到应用程序的特定部分之中,而不会使整个应用程序崩溃。这可以减少应用程序的整体宕机时间,并使它们对问题更有抵御能力。

不均匀的容量需求——在企业数据中心内部部署的传统应用程序通常具有一致的使用模式,这些模式会随着时间的推移而定期出现,这使这种类型的应用程序的容量规划变得很简单。但在一个基于云的应用中,Twitter上的一条简单推文或Slashdot上的一篇文章就能够极大带动对基于云计算的应用的需求。

因为微服务应用程序被分解成可以彼此独立部署的小组件,所以能够更容易将重点放在正处于高负载的组件上,并将这些组件在云中的多个服务器上进行水平伸缩。

本章的内容会包含在业务问题中构建和识别微服务的基础知识,构建微服务的骨架,然后理解在生产环境中成功部署和管理微服务的运维属性。

要想成功设计和构建微服务,开发人员需要像警察向目击证人讯问犯罪活动一样着手处理微服务。即使每个证人看到同一事件发生,他们对犯罪活动的解释也是根据他们的背景、他们所看重的东西(例如,给予他们动机的东西),以及在那个时刻目睹这个事件所带来的环境压力塑造出来的。每个参与者都有他们自己认为重要的视角(和偏见)。

就像一名成功的警察试图探寻真相一样,构建一个成功的微服务架构的过程需要结合软件开发组织内多个人的视角。尽管交付整个应用程序需要的不仅仅是技术人员,但我相信,成功的微服务开发的基础是从以下3个关键角色的视角开始的。

架构师——架构师的工作是看到大局,了解应用程序如何分解为单个微服务,以及微服务如何交互以交付解决方案。

软件开发人员——软件开发人员编写代码并详细了解如何将编程语言和该语言的开发框架用于交付微服务。

DevOps工程师——DevOps工程师不仅为生产环境而且为所有非生产环境提供服务部署和管理的智慧。DevOps工程师的口号是:保障每个环境中的一致性和可重复性。

本章将演示如何从这些角色的视角使用Spring Boot和Java设计和构建一组微服务。到本章结束时,读者将有一个可以打包并部署到云的服务。


喜欢的朋友可以添加我们的微信账号:

51CTO读书频道二维码


51CTO读书频道活动讨论群:365934973

【责任编辑:book TEL:(010)68476606】

回书目   上一节   下一节
点赞 0
分享:
大家都在看
猜你喜欢

读 书 +更多

计算机病毒防范艺术

本书由Symantec首席反病毒研究员执笔,是讲述现代病毒威胁、防御技术和分析工具的权威指南。与多数讲述计算机病毒的书籍不同,本书完全是...

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊