应用程序的架构演变,微服务不是终点

本文涉及的产品
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
简介: 在信息量剧增的大背景下,新的问题层出不穷,变化多端而且变形的速度越来越快,新形态的存续时间越来越短。这个时候,创新业务模式、创新技术架构,成为必须。

近些年来,应用程序的架构一直在演变,这个变化过程是由什么力量所驱动呢?它的变化方向又是由什么所决定的呢?开宗明义,应用程序架构,作为一个因变量,它的自变量是互联网带来的信息量剧增。

为什么这么说?我们先看下信息量的增长态势。

举一个例子,维基百科,它本质上是百科全书结合互联网所产生的新形态。全球上百万人的线上协作成就了它。它一改纸质《大英百科全书》等由专家编写、校对的传统,访问网站的普通人,都可以自由编辑上面的词条。截止目前,整个维基百科网站的总编辑次数超过10亿次,所收录的词条数超过450万篇。对比纸质《大英百科全书》,其条目数是10万篇,与维基百科有几十倍的落差,由于它是纸质的,更新速度也远不及维基百科。这意味着因为互联网的出现,单百科这一项,信息量就有几十、上百倍爆炸式增长。

再举一个例子,淘宝,它本质上是商品交易市场结合互联网的新形态。截止目前,淘宝的卖家数超过百万,注册买家数超过5亿,在线商品数超过8亿,每天有几千万的访客,每分钟可以达成几万笔商品交易,供给侧和需求侧的规模史无前例。这些数字是传统线下商圈所无法想象、无法比拟的。这意味着因为互联网的出现,单零售这一项,信息量有了几万、几十万倍的爆炸式增长。

不积跬步无以至千里,不积小流无以至江海。量变引发质变,而量的变化需要一个过程。我们回顾信息量变化的过程,发现它的变化呈现加速度的趋势,是指数级变化。具体而言,把信息量的变化剖判开来,分为供给侧和需求侧。作为变化中的供给侧,也就是提供服务的一方,若想在信息量增长的洪流中不被淘汰、并谋求最大利益,即挣更多需求侧的钱。就必须与其他供给侧激烈竞争,致胜的关键是通过创新来进行营销手段的丰富和服务能力的升级。

以电商平台为例,我们看它变化出了怎样的营销手段。

  • 丰富促销活动,如秒杀、荷兰式拍卖、传统节日和线上购物节的打折、满减、拼团等等。
  • 扩大营销入口数量,增加移动端,如App、微商城、微信小程序、支付宝小程序。
  • 精准营销。利用历史数据对用户进行分析,提供个性化服务,如定向优惠券、商品推荐。甚至,进行大数据杀熟。
  • 其他种种。

这些营销手段的落地,需要技术架构有力支撑。由于可扩展性、可用性、可靠性及应对海量并发等能力的不足,单体应用,明显扛不住了。这个形势下,为寻求问题的解决,新架构势必产生,微服务架构就是其中的一种。

信息量的增加,导致了竞争的加剧,进而导致了业务模式的变化,又进而导致了技术架构的变化,即应用程序架构的变化。自此,从自变量到因变量的逻辑线,打通了。

微服务架构是一个怎样的架构?我们知道,任何创新,都是要素的拆分和重新组合。我们看应用程序是如何拆分的,又是如何组合的,就能看清创新的面目。

还是以电商平台为例,它的应用可以这样拆分。
_1
这个拆分过程中,大量的冗余代码被删除。这些拆出来的各个微服务,构成一个控制层。所有的前端,都可以从这个控制层获取所需的数据。

同时,共用的数据库也被拆分,所有持久化层相互隔离,由各个服务自己负责。另外,为了提高系统的实时性,还加入了消息队列机制。

新的组合方式,由于变得复杂化,也带来了新问题。各个微服务之间,构成了彼此依赖的关系。一个服务发生故障,就可能会产生雪崩效用,导致整个系统故障。而且,更要命的是,定位故障点变得非常困难。之前的单体应用,排查问题通常是看一下日志,研究错误信息和调用堆栈。现在可怎么办?

可以从两方面入手,一方面尽量减少故障发生的概率,另一方面降低故障造成的影响。减少故障发生的概率,可以通过监控来实现。比如,采用Prometheus作为指标采集器,用Grafana配置监控界面和邮件告警。同时用链路跟踪,来定位问题。通过引入网关,来实现权限控制和服务治理。

在降低故障造成的影响方面,有熔断、服务降级、限流三大法宝。玩法也是丰富多样。

总结

在信息量剧增的大背景下,新的问题层出不穷,变化多端而且变形的速度越来越快,新形态的存续时间越来越短。这个时候,创新业务模式、创新技术架构,成为必须。而创新的关键,是发现变化最快的那个组件。把它和其他关键组件拆分出来,进行重新的组合。这一过程,附带产生的问题,则需要,引入其他模块,来做配套。微服务不是技术架构演变的终点,Serverless、FaaS等等这些还在台下等着粉墨登场,书写新的时代。

相关文章
|
3天前
|
敏捷开发 监控 数据管理
构建高效微服务架构的五大关键策略
【4月更文挑战第20天】在当今软件开发领域,微服务架构已经成为一种流行的设计模式,它允许开发团队以灵活、可扩展的方式构建应用程序。本文将探讨构建高效微服务架构的五大关键策略,包括服务划分、通信机制、数据管理、安全性考虑以及监控与日志。这些策略对于确保系统的可靠性、可维护性和性能至关重要。
|
3天前
|
消息中间件 监控 持续交付
构建高效微服务架构:后端开发的进阶之路
【4月更文挑战第20天】 随着现代软件开发的复杂性日益增加,传统的单体应用已难以满足快速迭代和灵活部署的需求。微服务架构作为一种新兴的分布式系统设计方式,以其独立部署、易于扩展和维护的特点,成为解决这一问题的关键。本文将深入探讨微服务的核心概念、设计原则以及在后端开发实践中如何构建一个高效的微服务架构。我们将从服务划分、通信机制、数据一致性、服务发现与注册等方面入手,提供一系列实用的策略和建议,帮助开发者优化后端系统的性能和可维护性。
|
5天前
|
机器学习/深度学习 运维 Prometheus
探索微服务架构下的系统监控策略
【4月更文挑战第18天】在当今快速迭代和持续部署盛行的软件工程实践中,微服务架构因其灵活性和可扩展性受到企业青睐。然而,随着服务的细粒度拆分和网络通信的增加,传统的监控手段已不再适用。本文将探讨在微服务环境中实施有效系统监控的策略,包括日志聚合、性能指标收集、分布式追踪以及异常检测等关键技术实践,旨在为读者提供构建稳定、可靠且易于维护的微服务系统的参考指南。
10 0
|
5天前
|
监控 持续交付 开发者
构建高效微服务架构:后端开发的新趋势
【4月更文挑战第18天】在数字化转型的浪潮中,微服务架构已成为企业提升系统灵活性、加速产品迭代的关键。此文深入探讨了构建高效微服务架构的实践方法,包括服务划分原则、容器化部署、持续集成/持续部署(CI/CD)流程以及监控与日志管理等关键技术点。通过分析具体案例,揭示了微服务在提高开发效率、降低维护成本及促进团队协作方面的显著优势。
|
6天前
|
负载均衡 Java 开发者
细解微服务架构实践:如何使用Spring Cloud进行Java微服务治理
【4月更文挑战第17天】Spring Cloud是Java微服务治理的首选框架,整合了Eureka(服务发现)、Ribbon(客户端负载均衡)、Hystrix(熔断器)、Zuul(API网关)和Config Server(配置中心)。通过Eureka实现服务注册与发现,Ribbon提供负载均衡,Hystrix实现熔断保护,Zuul作为API网关,Config Server集中管理配置。理解并运用Spring Cloud进行微服务治理是现代Java开发者的关键技能。
|
7天前
|
人工智能 Serverless 数据处理
利用阿里云函数计算实现 Serverless 架构的应用
阿里云函数计算是事件驱动的Serverless服务,免服务器管理,自动扩展资源。它降低了基础设施成本,提高了开发效率,支持Web应用、数据处理、AI和定时任务等多种场景。通过实例展示了如何用Python实现图片压缩应用,通过OSS触发函数自动执行。阿里云函数计算在云计算时代助力企业实现快速迭代和高效运营。
43 0
|
7天前
|
监控 JavaScript 安全
构建微服务架构下的API网关
【4月更文挑战第15天】在微服务架构中,API网关扮演着至关重要的角色。它作为系统的唯一入口,不仅负责请求的路由、负载均衡和认证授权,还涉及到监控、日志记录和服务熔断等关键功能。本文将探讨如何构建一个高效且可靠的API网关,涵盖其设计原则、核心组件以及实现策略,旨在为后端开发人员提供一套实用的指导方案。
22 4
|
15天前
|
API 数据库 开发者
构建高效可靠的微服务架构:后端开发的新范式
【4月更文挑战第8天】 随着现代软件开发的复杂性日益增加,传统的单体应用架构面临着可扩展性、维护性和敏捷性的挑战。为了解决这些问题,微服务架构应运而生,并迅速成为后端开发领域的一股清流。本文将深入探讨微服务架构的设计原则、实施策略及其带来的优势与挑战,为后端开发者提供一种全新视角,以实现更加灵活、高效和稳定的系统构建。
18 0
|
13天前
|
Kubernetes 安全 Java
构建高效微服务架构:从理论到实践
【4月更文挑战第9天】 在当今快速迭代与竞争激烈的软件市场中,微服务架构以其灵活性、可扩展性及容错性,成为众多企业转型的首选。本文将深入探讨如何从零开始构建一个高效的微服务系统,覆盖从概念理解、设计原则、技术选型到部署维护的各个阶段。通过实际案例分析与最佳实践分享,旨在为后端工程师提供一套全面的微服务构建指南,帮助读者在面对复杂系统设计时能够做出明智的决策,并提升系统的可靠性与维护效率。