架构师必须要知道的阿里的中台战略与微服务

本文涉及的产品
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
简介:   传统企业平台都是烟囱式的系统架构,企业内部为了迎合业务发展不停的打造各种系统,导致各系统间的重复功能建设和维护带来的重复投资。重复投资不仅消耗的是人力,财力还有时间。但打通烟囱式系统间交互的集成和协作成本高昂,各大企业不得不借助ESB产品,构建企业服务总线,打通各系统间的交互问题。

  传统企业平台都是烟囱式的系统架构,企业内部为了迎合业务发展不停的打造各种系统,导致各系统间的重复功能建设和维护带来的重复投资。重复投资不仅消耗的是人力,财力还有时间。但打通烟囱式系统间交互的集成和协作成本高昂,各大企业不得不借助ESB产品,构建企业服务总线,打通各系统间的交互问题。

  但这种借助ESB“中心化”的服务架构缺点也有不少,“中心化”架构的所有服务调用者和服务提供者之间的交互都必须通过这个中心点,而这个中心点的能力是很难进行扩展的,导致这中心会成为一个瓶颈。

2015年阿里巴巴集团启动了中台战略,目标是要构建符合互联网大数据时代的,具有创新性、灵活性的“大中台、小前台”的机制,即作为前台的一线业务会更敏捷、更快速的适用瞬息万变的市场,而中台将集合整个集团的运营数据能力,产品技术能力,对各前台业务形成强有力的支撑。整体内容如下:

 

阿里的“大中台、小前台”架构

  起初,阿里只有一个淘宝事业部,后来成立了天猫事业部,此时淘宝的技术团队同时支撑着这两个事业部。当时的淘宝和天猫的电商系统像我们很多大型企业的一样是分为两套独立的烟囱式体系,两套体系中都包含的有商品、交易、支付、评价、物流等功能。因为上述原因,阿里集团又成立了共享业务事业部,其成员主要来自之前的淘宝技术团队,同时将两套电商业务做了梳理和沉淀,将两个平台中公共的、通用的业务功能沉淀到共享事业部,避免重复建设和维护。后来上线的聚划算、1688、菜鸟物流等业务,均是基于这个“大中台,小前台”思路建设的。如下图所示:

   “大中台、小前台”架构主要集中在业务共享服务层,业务共享服务团队,有独立的团队来做,也更利于业务的沉淀,降低研发成本,提高研发效率。打破了产品壁垒,之前是系统之间要数据,现在是都去找共享服务中心要数据,共享服务中心提供统一的,标准的数据。减少了系统间交互、团队间协作的成本。站在巨人的肩膀上。新产品研发不用考虑之前已有的东西,可以快速孵化新的产品,试错成本低,产品敢于创新,敢于拥抱变化,原来追竞争对手都很困难,现在相当于竞争对手的产品经理不停的给我们提供新点子。可持续发展,技术和业务能力能够沉淀积累。

“大中台、小前台”与微服务的关系

  微服务体现去中心化、天然分布式,与阿里的中台战略思想类似,是战略的具体实现方式的一种。现有架构师可以学习这种模式来解决企业本身的应用高并发、高可用、运维等难题,也是现有互联网经典架构,毕竟是经过阿里实践过的,除了BAT,Uber、网易、美团、京东等互联网公司都在很早前就实现了平台微服务化。

为什么要微服务化?

  在传统单体或SOA架构下,应用如果频繁升级更新,开发团队非常痛苦。企业的业务应用经过多年IT建设,系统非常庞大,要改动其中任何一小部分,都需要重新部署整个应用,敏捷开发和快速交付无从谈起。

  传统企业在长期的IT建设过程中,通常大量使用外包团队,这导致采用的技术栈之间差异较大,统一管控和运维要求更高。需要运维7*24小时全天候值守、在线升级,并快速响应。

  在此时脱颖而出的微服务技术,面对上述困惑几乎浑身优点:独立开发、独立部署、独立发布,去中心化管理,支持高并发高可用,支持丰富技术栈,企业可以根据需要灵活技术选型。

实践微服务架构的选择

微服务架构中所包含的内容:

   微服务是将企业通用服务按业务化分成一个个单体服务,增强可用性、服务易扩展、减少开发成本、减少服务发布对整个平台的影响。微服务是一种思想,实现有很多方式,企业转由单个系统转向微服务就要考虑很多问题,比如技术选型、业务拆分问题、高可用、服务通信、服务发现和治理、集群容错、配置管理、数据一致性问题、康威定律、分布式调用跟踪、CI/CD、微服务测试,以及调度和部署等等,这并非一些简单招数能够化解。

  微服务框架必须能够达到借助虚拟化平台,能够按需创建机器并调整大小,借助基础设施的自动化从一台机器扩展到多台,拥有业务监控预警、异常熔断等等功能,现有框架有Dubbo和SpringCloud,Dubbo是RPC服务治理框架,和SpringCloud一样具备服务注册、发现、路由、负载均衡等能力。

 Dubbo和Spring Cloud有何不同?

首先做一个简单的功能对比:

  从上图可以看出Dubbo的功能只是Spring Cloud体系的一部分,Dubbo已停更了几年,虽然最近宣布加强了开源支持,但对于其它框架来说已经非常滞后了。
需要说明的是 Dubbo 是 SOA 时代的产物,它的关注点主要在于服务的调用,流量分发、流量监控和熔断。而 Spring Cloud 诞生于微服务架构时代,考虑的是微服务治理的方方面面,另外由于依托了 Spirng、Spirng Boot 的优势之上,两个框架在开始目标就不一致,Dubbo 定位服务治理、Spirng Cloud 是一个生态。

那如何做技术选型

相信更多的架构师为选择Spring Cloud生态,引用网友的理由:

1)从两个公司的背景来谈:Dubbo,是阿里巴巴服务化治理的核心框架,并被广泛应用于中国各互联网公司;Spring Cloud是大名鼎鼎的Spring家族的产品。阿里巴巴是一个商业公司,虽然也开源了很多的顶级的项目,但从整体战略上来讲,仍然是服务于自身的业务为主。Spring专注于企业级开源框架的研发,不论是在中国还是在世界上使用都非常广泛,开发出通用、开源、稳健的开源框架就是他们的主业。

2)从社区活跃度这个角度来对比,Dubbo虽然也是一个非常优秀的服务治理框架,并且在服务治理、灰度发布、流量分发这方面做的比Spring Cloud还好,除过当当网在基础上增加了rest支持外,已有两年多的时间几乎都没有任何更新了。在使用过程中出现问题,提交到github的Issue也少有回复。

相反Spring Cloud自从发展到现在,仍然在不断的高速发展,从github上提交代码的频度和发布版本的时间间隔就可以看出,现在Spring Cloud即将发布2.0版本,到了后期会更加完善和稳定。

3) 从整个大的平台架构来讲,dubbo框架只是专注于服务之间的治理,如果我们需要使用配置中心、分布式跟踪这些内容都需要自己去集成,这样无形中使用dubbo的难度就会增加。Spring Cloud几乎考虑了服务治理的方方面面,更有Spring Boot这个大将的支持,开发起来非常的便利和简单。

4)从技术发展的角度来讲,Dubbo刚出来的那会技术理念还是非常先进,解决了各大互联网公司服务治理的问题,中国的各中小公司也从中受益不少。经过了这么多年的发展,互联网行业也是涌现了更多先进的技术和理念,Dubbo一直停滞不前,自然有些掉队,有时候我个人也会感到有点可惜,如果Dubbo一直沿着当初的那个路线发展,并且延伸到周边,今天可能又是另一番景象了。

  Spring 推出Spring Boot/Cloud也是因为自身的很多原因。Spring最初推崇的轻量级框架,随着不断的发展也越来越庞大,随着集成项目越来越多,配置文件也越来越混乱,慢慢的背离最初的理念。随着这么多年的发展,微服务、分布式链路跟踪等更多新的技术理念的出现,Spring急需一款框架来改善以前的开发模式,因此才会出现Spring Boot/Cloud项目,我们现在访问Spring官网,会发现Spring Boot和Spring Cloud已经放到首页最重点突出的三个项目中的前两个,可见Spring对这两个框架的重视程度。

  因此可以看到SpringCloud良好的生态是非常重要的,这里只讲到至SpringCloud实现微服务,具体SpringCloud微服务的详情后面再介绍不做多讲,还有与微服务紧密相关的容器技术也是相当重要的,还有微服务的DevOps自动化运维到智能化运维后面再作主题介绍。

   最后要说的是由于服务能力的集中管控,很大程度会促进我们一体化运维的能力,但在“大中台、小前台”的模式下,每一个服务都负责对N多个前端业务应用提供支持,这就要求运维在信息安全、备份、监控等方面要有更强的能力,这也将改变企业的组织架构调整。

   以上是每一位架构师都需要不断学习的内容,相关衍生出来的内容更多,这里只作抛砖引玉,文中部分引用了圈内大咖的内容 ,在此感谢他们的付出。

目录
相关文章
|
3天前
|
负载均衡 测试技术 持续交付
高效后端开发实践:构建可扩展的微服务架构
在当今快速发展的互联网时代,后端开发扮演着至关重要的角色。本文将重点探讨如何构建可扩展的微服务架构,以及在后端开发中提高效率的一些实践方法。通过合理的架构设计和技术选型,我们可以更好地应对日益复杂的业务需求,实现高效可靠的后端系统。
|
3天前
|
监控 持续交付 API
构建高效可扩展的微服务架构
在当今快速迭代和竞争激烈的软件市场中,构建一个高效、可扩展且易于维护的后端系统变得尤为重要。微服务架构作为一种流行的分布式系统设计方式,允许开发者将应用程序划分为一系列小型、自治的服务,每个服务负责执行特定的业务功能。本文将探讨如何利用现代技术栈搭建一个符合这些要求的微服务架构,并讨论其潜在的挑战与解决方案。我们将涵盖服务划分策略、容器化、服务发现、API网关、持续集成/持续部署(CI/CD)以及监控和日志管理等关键主题,以帮助读者构建出既可靠又灵活的后端系统。
|
5天前
|
监控 Kubernetes 持续交付
构建高效可扩展的微服务架构:后端开发实践指南
在数字化转型的浪潮中,企业对软件系统的要求日益提高,追求快速响应市场变化、持续交付价值成为核心竞争力。微服务架构以其灵活性、模块化和独立部署的特点,成为解决复杂系统问题的有效途径。本文将深入探讨如何构建一个高效且可扩展的微服务架构,涵盖关键设计原则、技术选型及实践案例,为后端开发者提供一条清晰的指导路线,帮助其在不断变化的技术环境中保持竞争力。
111 3
|
4天前
|
消息中间件 敏捷开发 运维
构建高效可靠的微服务架构:策略与实践
随着现代软件开发的复杂性增加,微服务架构逐渐成为企业解决大型应用系统分解、敏捷开发和持续部署问题的有效手段。本文深入探讨了构建一个高效且可靠的微服务架构的关键策略,包括服务的合理划分、通信机制的选择、数据一致性保障以及容错处理。通过分析这些策略在具体案例中的应用,我们旨在为开发者提供一套可行的微服务设计及实施指南。
108 6
|
4天前
|
监控 数据管理 API
构建高效微服务架构:后端开发的新趋势
在现代软件开发领域,随着业务需求的不断复杂化以及敏捷迭代的加速,传统的单体应用架构逐渐暴露出其局限性。微服务架构作为一种新的解决方案,以其高度模块化、独立部署和可扩展性,正成为后端开发领域的新趋势。本文将探讨微服务架构的核心概念,分析其优势与面临的挑战,并提供实施高效微服务的策略和最佳实践,帮助读者理解如何利用这一架构模式提升系统的可靠性、灵活性和可维护性。
112 5
|
7天前
|
人工智能 运维 监控
构建高性能微服务架构:现代后端开发的挑战与策略构建高效自动化运维系统的关键策略
【2月更文挑战第30天】 随着企业应用的复杂性增加,传统的单体应用架构已经难以满足快速迭代和高可用性的需求。微服务架构作为解决方案,以其服务的细粒度、独立性和弹性而受到青睐。本文将深入探讨如何构建一个高性能的微服务系统,包括关键的设计原则、常用的技术栈选择以及性能优化的最佳实践。我们将分析微服务在处理分布式事务、数据一致性以及服务发现等方面的挑战,并提出相应的解决策略。通过实例分析和案例研究,我们的目标是为后端开发人员提供一套实用的指南,帮助他们构建出既能快速响应市场变化,又能保持高效率和稳定性的微服务系统。 【2月更文挑战第30天】随着信息技术的飞速发展,企业对于信息系统的稳定性和效率要求
|
4天前
|
API 持续交付 开发者
构建高效微服务架构:后端开发的新范式
在数字化转型和技术迭代的浪潮中,微服务架构以其灵活性、可扩展性和独立性成为现代后端开发的重要趋势。本文深入探讨了构建高效微服务架构的关键要素,包括服务划分策略、容器化部署、API网关设计以及持续集成与持续部署(CI/CD)的实践。通过分析这些组件和流程,我们旨在为后端开发者提供一套实用的指南,帮助他们构建和维护一个高性能、可靠的微服务系统。
20 5
|
4天前
|
消息中间件 缓存 API
微服务架构下的API网关性能优化实践
在现代的软件开发中,微服务架构因其灵活性和可扩展性被广泛采用。随着服务的细分与增多,API网关作为微服务架构中的关键组件,承担着请求路由、负载均衡、权限校验等重要职责。然而,随着流量的增长和业务复杂度的提升,API网关很容易成为性能瓶颈。本文将深入探讨API网关在微服务环境中的性能优化策略,包括缓存机制、连接池管理、异步处理等方面的具体实现,旨在为开发者提供实用的性能提升指导。
|
5天前
|
Prometheus 监控 API
构建高效微服务架构:后端开发的新趋势
随着现代软件开发的复杂性增加,传统的单体应用已难以满足快速迭代与灵活部署的需求。微服务架构作为解决这一问题的有效手段,其设计理念和实践方法已成为后端开发领域的热门话题。本文将探讨如何构建一个高效的微服务架构,涵盖设计原则、技术选型、以及实践中可能遇到的挑战,为后端开发者提供一套可行的参考方案。
12 2
|
6天前
|
缓存 负载均衡 监控
构建高效微服务架构:API网关的作用与实践
【2月更文挑战第31天】 在当今的软件开发领域,微服务架构已成为实现系统高度模块化和易于扩展的首选方法。然而,随着微服务数量的增加,确保通信效率和管理一致性变得尤为重要。本文将探讨API网关在微服务架构中的核心角色,包括其在请求路由、安全性、负载均衡以及聚合功能方面的重要性。我们将通过具体案例分析,展示如何利用API网关优化后端服务,并讨论实施过程中的最佳实践和常见挑战。

相关产品

  • 微服务引擎
  • 服务网格