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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

总结

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

相关文章
|
14天前
|
缓存 负载均衡 JavaScript
探索微服务架构下的API网关模式
【10月更文挑战第37天】在微服务架构的海洋中,API网关犹如一座灯塔,指引着服务的航向。它不仅是客户端请求的集散地,更是后端微服务的守门人。本文将深入探讨API网关的设计哲学、核心功能以及它在微服务生态中扮演的角色,同时通过实际代码示例,揭示如何实现一个高效、可靠的API网关。
|
12天前
|
Cloud Native 安全 数据安全/隐私保护
云原生架构下的微服务治理与挑战####
随着云计算技术的飞速发展,云原生架构以其高效、灵活、可扩展的特性成为现代企业IT架构的首选。本文聚焦于云原生环境下的微服务治理问题,探讨其在促进业务敏捷性的同时所面临的挑战及应对策略。通过分析微服务拆分、服务间通信、故障隔离与恢复等关键环节,本文旨在为读者提供一个关于如何在云原生环境中有效实施微服务治理的全面视角,助力企业在数字化转型的道路上稳健前行。 ####
|
12天前
|
Dubbo Java 应用服务中间件
服务架构的演进:从单体到微服务的探索之旅
随着企业业务的不断拓展和复杂度的提升,对软件系统架构的要求也日益严苛。传统的架构模式在应对现代业务场景时逐渐暴露出诸多局限性,于是服务架构开启了持续演变之路。从单体架构的简易便捷,到分布式架构的模块化解耦,再到微服务架构的精细化管理,企业对技术的选择变得至关重要,尤其是 Spring Cloud 和 Dubbo 等微服务技术的对比和应用,直接影响着项目的成败。 本篇文章会从服务架构的演进开始分析,探索从单体项目到微服务项目的演变过程。然后也会对目前常见的微服务技术进行对比,找到目前市面上所常用的技术给大家进行讲解。
30 1
服务架构的演进:从单体到微服务的探索之旅
|
10天前
|
消息中间件 监控 安全
后端架构演进:从单体到微服务####
在数字化转型的浪潮中,企业应用的后端架构经历了从传统单体架构到现代微服务架构的深刻变革。本文探讨了这一演进过程的背景、驱动力、关键技术及面临的挑战,揭示了如何通过微服务化实现系统的高可用性、扩展性和敏捷开发,同时指出了转型过程中需克服的服务拆分、数据管理、通信机制等难题,为读者提供了一个全面理解后端架构演变路径的视角。 ####
28 8
|
11天前
|
Cloud Native 安全 API
云原生架构下的微服务治理策略与实践####
—透过云原生的棱镜,探索微服务架构下的挑战与应对之道 本文旨在探讨云原生环境下,微服务架构所面临的关键挑战及有效的治理策略。随着云计算技术的深入发展,越来越多的企业选择采用云原生架构来构建和部署其应用程序,以期获得更高的灵活性、可扩展性和效率。然而,微服务架构的复杂性也带来了服务发现、负载均衡、故障恢复等一系列治理难题。本文将深入分析这些问题,并提出一套基于云原生技术栈的微服务治理框架,包括服务网格的应用、API网关的集成、以及动态配置管理等关键方面,旨在为企业实现高效、稳定的微服务架构提供参考路径。 ####
38 5
|
13天前
|
Kubernetes 负载均衡 Cloud Native
云原生架构下的微服务治理策略
随着云原生技术的不断成熟,微服务架构已成为现代应用开发的主流选择。本文探讨了在云原生环境下实施微服务治理的策略和方法,重点分析了服务发现、负载均衡、故障恢复和配置管理等关键技术点,以及如何利用Kubernetes等容器编排工具来优化微服务的部署和管理。文章旨在为开发者提供一套实用的微服务治理框架,帮助其在复杂的云环境中构建高效、可靠的分布式系统。
31 5
|
13天前
|
负载均衡 监控 Cloud Native
云原生架构下的微服务治理策略与实践####
在数字化转型浪潮中,企业纷纷拥抱云计算,而云原生架构作为其核心技术支撑,正引领着一场深刻的技术变革。本文聚焦于云原生环境下微服务架构的治理策略与实践,探讨如何通过精细化的服务管理、动态的流量调度、高效的故障恢复机制以及持续的监控优化,构建弹性、可靠且易于维护的分布式系统。我们将深入剖析微服务治理的核心要素,结合具体案例,揭示其在提升系统稳定性、扩展性和敏捷性方面的关键作用,为读者提供一套切实可行的云原生微服务治理指南。 ####
|
14天前
|
监控 持续交付 Docker
Docker 容器化部署在微服务架构中的应用有哪些?
Docker 容器化部署在微服务架构中的应用有哪些?
|
14天前
|
监控 持续交付 Docker
Docker容器化部署在微服务架构中的应用
Docker容器化部署在微服务架构中的应用
|
14天前
|
安全 持续交付 Docker
微服务架构和 Docker 容器化部署的优点是什么?
微服务架构和 Docker 容器化部署的优点是什么?
下一篇
无影云桌面