|
|
|
|
移动端

1.6 为什么要改变构建应用的方式

《Spring微服务实战》第1章欢迎迈入云世界,Spring,本书主要介绍微服务架构,以及为什么应该考虑采用微服务架构来构建应用。本节为大家介绍为什么要改变构建应用的方式。

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

技术沙龙 | 6月30日与多位专家探讨技术高速发展下如何应对运维新挑战!


1.6 为什么要改变构建应用的方式

我们正处于历史的拐点。现代社会的几乎所有方面都可以通过互联网连接在一起。习惯于为当地市场服务的公司突然发现,他们可以接触到全球的客户群,全球更大的客户群一起涌进来的同时也带来了全球竞争。这些竞争压力意味着以下力量正在影响开发人员考虑构建应用程序的方式。

复杂性上升——客户期望组织的所有部门都知道他们是谁。与单个数据库通信并且不与其他应用程序集成的“孤立的”应用程序已不再是常态。如今,应用程序不仅需要与多个位于公司数据中心内的服务和数据库进行通信,还需要通过互联网与外部服务提供商的服务和数据库进行通信。

客户期待更快速的交付——客户不再希望等待软件包的下一次年度发布或整体版本更新。相反,他们期望软件产品中的功能被拆分,以便在几周(甚至几天)内即可快速发布新功能,而无需等待整个产品发布。

性能和可伸缩性——全球性的应用程序使预测应用程序将处理多少事务量以及何时触发该事务量变得非常困难。应用程序需要快速跨多个服务器进行扩大,然后在事务量高峰过去时进行收缩。

客户期望他们的应用程序可用——因为客户与竞争对手之间只有点击一下鼠标的距离,所以企业的应用程序必须具有高度的弹性。应用程序中某个部分的故障或问题不应该导致整个应用程序崩溃。

为了满足这些期望,作为应用开发人员,我们不得不接受这样一个悖论:构建高可伸缩性和高度冗余的应用程序。我们需要将应用程序分解成可以互相独立构建和部署的小型服务。如果将应用程序“分解”为小型服务,并将它们从单体制品中转移出来,那么就可以构建具有下面这些特性的系统。

灵活性——可以将解耦的服务进行组合和重新安排,以快速交付新的功能。一个正在使用的代码单元越小,更改代码越不复杂,测试部署代码所需的时间越短。

有弹性——解耦的服务意味着应用程序不再是单个“泥浆球”,在这种架构中其中一部分应用程序的降级会导致整个应用程序失败。故障可以限制在应用程序的一小部分之中,并在整个应用程序遇到中断之前被控制。这也使应用程序在出现不可恢复的错误的情况下能够优雅地降级。

可伸缩性——解耦的服务可以轻松地跨多个服务器进行水平分布,从而可以适当地对功能 / 服务进行伸缩。单体应用程序中的所有逻辑是交织在一起的,即使只有一小部分应用程序是瓶颈,整个应用程序也需要扩展。小型服务的扩展是局部的,成本效益更高。

为此,当我们开始讨论微服务时,请记住下面一句话:小型的、简单的和解耦的服务=可伸缩的、有弹性的和灵活的应用程序。


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

51CTO读书频道二维码


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

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

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

读 书 +更多

软件设计师考试全真模拟试题及解析

本书是按照全国计算机技术与软件专业技术资格(水平)考试《软件设计师考试大纲》的要求,参照《软件设计师教程》及近年来考试试题编写的,...

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊