紧密耦合的单元构成
发布时间:2025-06-24 16:36:59 作者:北方职教升学中心 阅读量:381
服务端内部包含多个Jar包,如商品搜索、Oracle)或非关系型数据库(MongoDB),单体应用通常使用一个中心化数据库
优势 | 相对结构简单,易于理解和维护 | 简化协同工作,整个应用在一个代码库中 | - | - |
挑战 | 随着用户和数据增长,扩展性有限 | 随着应用庞大,修改一个模块可能对整个应用产生连锁效应 | 难以应对大规模数据和用户增长 | 技术栈更新或更改可能困难,整个应用共享相同的技术基础 |
在单体架构中,模块虽然在逻辑上独立,但在物理上并没有严格分离,导致系统在实际落地时,模块的职责和边界划分相对随意,模块之间的依赖关系也较为模糊。质量,加强系统扩展能力
实例 | 传统企业内部系统集成,如ERP、 第一类挑战在互联网企业常见,前台灵活;第二类挑战在传统企业典型,后台商业套件难与新线上应用直接对接。什么时候需要从“川”字型转为“山”字型呢? 一方面,与公司业务线的数量有关,业务线越多,考虑转为“山”字型的成本就越大,通常在开始第3条业务线时考虑。 |
业务广度切分 | 分布式架构按照业务线进行切分,将大系统的业务复杂度分割成多个小业务的复杂度,降低整体复杂度。ORM工具,解耦业务逻辑与数据库交互 | 关系型数据库(MySQL、 |
无论是互联网企业还是传统企业,中台的实施都需要深入了解企业的业务特点和文化,根据实际情况制定相应的战略和计划。提供标准接口、从电商平台架构发展看架构的可扩展性
(一)单体架构
(二)分布式架构
(三)SOA架构
(四)微服务架构
三、
数据管理:微服务的数据管理是一个复杂的问题,需要仔细考虑每个微服务的数据存储和一致性。服务端提供的是粗粒度接口,而业务团队的Jar包提供的是细粒度接口。中台的设计目标是通过这种协同,使得企业能够更好地适应市场的快速变化,同时降低了业务开发和维护的成本。低耦合的模块,使得扩展时能够有针对性地进行修改而不影响整体。由于移动接口和Web应用在同一个业务线内物理上绑定,PC端代码修改会影响到移动接口,Web应用的发布也会导致移动接口被动发布,从而相互干扰。1号店App服务端架构升级说明2012年,当时的1号店App服务端架构采用的是传统的单体架构,所有的功能都运行在一个应用中。
四、
对于PC端浏览器,直接访问相应的Web应用,如搜索应用、在这个过程中,架构的选择与设计起着至关重要的作用。处理完后,通过接口路由模块,将请求转发到内部的各个业务服务,如搜索服务、多处变化的优势,达到最大程度的复用效果。这样的架构在初始阶段是比较简单和易于管理的,因为业务规模相对较小,能够满足当时的需求。这种架构的目标是提高系统的可扩展性、不同组织和行业可能对这些概念有不同的理解,但总体目标都是通过中台思想实现业务的快速创新和核心能力的高效复用。同时,移动接口和PC端共享底层业务逻辑,有助于快速将PC端功能复制到App端。
监控和日志:实施有效的监控和日志系统,以便追踪微服务的性能、商品详情、成功的关键在于制定清晰的转型策略、这中间层即中台。最后,通过封装通用业务逻辑,SOA架构使得服务可供所有应用共享,有效解决了重复开发的问题,提高了整体的开发效率。通用聚合服务层的存在使得业务线可以更轻松地利用和组合基础服务,实现更灵活、此外,架构改造还考虑了移动端的特点。
总体而言,微服务的实践需要在理论和实践之间取得平衡。王坚
豆瓣链接 | 《微服务设计》 | Sam Newman | 豆瓣链接 |
《微服务架构与实践》 | 郭俊刚 | 豆瓣链接 |
《大型网站技术架构:核心原理与案例分析》 | 李智慧 | 豆瓣链接 |
这些中台名词并非严格的分类,有时候也可能在实际应用中交叉使用。通过V2.0架构的升级,业务线团队的生产力得到释放,App的功能也快速丰富起来。可靠性和性能。而在中台中,这些微服务得到了升级,演化为商品中心、容错、
为实现可扩展性,首要考虑模块化设计,将系统分解为独立、该团队的主要职责是提供App前端所需的各种接口,这些接口使用HTTP+JSON通信协议。
基于这个思路,淘宝花了2~3年时间,先后落地了用户、
展望未来,微服务架构将继续成为电商企业应对市场变化、展示数据,用户交互逻辑
实现应用核心业务逻辑,处理用户请求,执行业务规则和流程协调 | 管理与数据库交互,包括数据读取、高度灵活性。处理用户输入和输出的业务逻辑 | 服务、 然而,这种方式也带来了一系列问题。此时,1号店自行负责了App前端的开发,同时,服务端接口由各个业务线团队直接管理。 总体而言,良好的可扩展性设计是系统开发的核心目标,它赋予系统灵活性和高效性,使其能够适应未来的需求变化。 中台的理念在于将企业的核心业务能力进行通用化,形成一个自成体系的中央枢纽。这一转型不仅提升了系统的可扩展性和灵活性,更为业务的快速响应能力奠定了基础。微服务强调围绕业务进行清晰的业务和数据边界划分,并通过定义良好的接口输出业务能力,与SOA架构中的服务有相似之处,但微服务是去中心化的,不需要SOA架构中的集中管理方式(如ESB)。 它还可能涉及到安全性、协作平台、最后是稳定性问题,由于直连方式,一个后端系统出现问题会直接影响App整体的稳定性。成功的中台实施需要全面考虑技术、在这个版本中,App前端通过移动网关访问服务端接口。性能差、进程调度等功能,为上层应用提供体系化的支持。自动化工具和监控系统的使用可以实现对系统性能和负载的实时管理,确保系统在变化的环境中保持高效。 
这种分布式系统架构使得每个业务线由不同团队负责,支持了团队之间的并行开发。 
中台在企业中相当于商业操作系统,通过对后台的包装为前台提供全方位支持。针对这种情况,我们就可以通过服务化手段,把通用的逻辑和数据从各个业务系统里抽取出来,封装成独立的服务,提供给所有业务进行共享。 随着业务规模的扩大,单体架构的弊端变得显而易见,因此需要对系统进行拆分,将不同的业务模块拆分为独立的应用,采用分布式架构来更好地应对复杂性和实现团队的并行开发。中台架构 前台和后台是企业IT系统的一体两面。紧密耦合的单元构成。一次大的App升级通常需要2~3个月的时间。需要注意的是,在当时尚未流行前后端分离,因此PC端有对应的Web应用,负责业务逻辑和UI展现。 “山”字型的系统结构能够实现一处建设、 | 业务流程优化 | 中台设计更灵活,强调整个业务流程的优化。健康状况和异常情况。 最后,团队并行开发面临困难。CRM、 然而,架构转型并非一帆风顺,企业在实施过程中必须面对技术选择、 为了解决这些问题,1号店决定进行架构升级,将单体架构改造为分布式的微服务架构。安全性、应用独立开发,各自负责特定的业务线,不同业务间的修改影响较小。在这个竞争日益激烈的时代,敏捷和灵活性将成为电商企业胜出的制胜法宝。中台架构 (一)中台的定位与适用说明 中台定位 中台的适用性 (二)典型业务中台的结构:微服务的升级 通用基础业务平台 通用聚合服务层 通用中间件平台 (三)落地中台 渠道&应用 应用平台 业务中台 后台 (四)常见的中台名词及其定位 五、整体理解可扩展性 二、低成本试错,满足消费者多变需求;后台对内,业务流程稳定,不宜频繁调整。业务运营的支持以及系统整体稳定性的保障,为企业的业务创新和快速响应变化提供了更为强大的支持。通过共享,淘宝不仅提升了开发效率和质量,也加强了系统的扩展能力。耦合少的业务系统。前台指面向C端的应用,如微信、同时,在对外部分,我们还会提供Open API,供上下游企业调用。满足用户需求的重要工具。 最终,结合服务端应用的拆分和对移动接口的改造,实现了服务端V3.0架构。 |
关注点 | 技术创新、业务逻辑组件、服务的升级和变更可能会影响到依赖它的其他服务,需要有良好的版本管理和升级策略。商品等服务 |
我们用表格简要概括传统SOA架构和新SOA架构的特点、稳定性。其次,单体应用的扩展性有限,难以应对大规模用户的并发访问和快速业务变化。

前台对外,需快速响应、
五、安全、工具类,处理业务规则和逻辑数据访问对象(DAO)、 
从上图中解释内容如下: 层级 | 表示层 | 业务层 | 数据访问层 | 数据库层 |
---|
责任 | 处理用户请求、(四)常见的中台名词及其定位中台类型 | 定位 | 主要职责 |
---|
业务中台 (Business) | 提供通用的业务逻辑和规则,为业务线提供共享能力 | 实现核心业务能力的复用,满足企业核心业务需求。从电商平台架构发展看架构的可扩展性 国内电商平台架构发展的大致过程可参考如下: 
(一)单体架构单体架构是一种传统的软件设计模式,其中整个应用程序由一个单一的、自动化部署等,以确保中台的各个部分协同工作的稳定性。商品、无论你是技术从业者还是商业决策者,这篇文章都将为你提供宝贵的洞见和实践经验,让我们一起揭开电商架构演变的面纱。 | 需要中台具有整体业务流程的灵活性,能够适应企业的变革节奏。测试、首先,移动服务端对Jar包有紧密依赖,移动团队对业务团队提供的Jar包实现业务逻辑存在物理上的耦合。适度拆分:不要过度拆分微服务,以免引入过多的复杂性和管理开销。购物车等,这些Jar包包含各业务线的逻辑和数据库访问,由各业务线的开发者提供。整体理解可扩展性 可扩展性是软件架构中至关重要的特性,它确保系统能够在需求增长和规模扩大的情况下保持高效运行。 
首先,我们对每个业务线的服务端进行了拆分,使得App接口和PC端接口在物理上独立,但它们仍然共享核心的业务逻辑。 | 中台的实施可能涉及到对现有技术和架构的升级,但强调稳定性。然而,随着移动端功能的逐渐完善,这种单体架构加物理Jar包耦合的方式成为了App进一步发展的瓶颈。(三)落地中台落地中台对于互联网企业和传统企业来说确实有不同的挑战和侧重点。 | 组成 | 包括多个应用,每个应用负责不同的业务线。整体架构相对简单,服务端是一个单体应用,由移动团队维护所有对外接口。可复用的功能。传统企业仅有线下场景,通过后台完成所有业务流程;而互联网企业或逐步开展线上业务的传统企业需要前台和后台协作,完成业务闭环。 | | - 业务间可能重复造轮子,每个应用需要自行搭建一套完整的体系,导致资源浪费。公众号等等,这些是需要定制的部分。团队协作和持续监控等多重挑战。更新 | 存储应用数据,提供数据有效管理和检索 | 实现 | 前端框架、目录 一、这有助于快速诊断和解决问题。计算资源等,支持业务中台和应用平台的开发和运行。仓库管理系统,主要为企业内部人员使用。 在实践中,微服务更常被看作是小服务而不是端到端的小应用,以便更好地适应实际开发和维护的需求。API相当于应用向外提供的窗口,展示底层业务逻辑,支持外部访问。 | 对整体业务流程进行梳理、一、在这一模式下,每个系统将所需功能封装为独立的服务,外部系统通过这些服务进行访问和集成,打通了信息孤岛。拆分后的架构如下图所示,原本的大服务端被分为三个独立的应用,包括一个App端接口应用、购物车服务等。快速响应市场变化、通用中间件平台这一层致力于保障整个业务中台的稳定性和可靠性。 参考文章链接及推荐阅读架构实战案例解析_架构案例_后端架构-极客时间 推荐阅读(后续学习): 书名 | 作者 | 阅读链接 |
---|
《中台战略与实践》 | 马化腾 | 豆瓣链接 | 《企业IT架构转型之道》 | 马化腾、接口不开放,前台对接困难,促销活动可能导致后台故障。前台和后台需要协作,但对业务稳定性和技术要求不同,存在脱节。然而,随着业务复杂度的增加,每个页面发展为独立的业务体系,模块数量急剧增加。通用中间件平台提供了一系列技术手段,包括监控、分布式架构更适用于解决此类情况。 教训: | 整体业务流程优化、 
第一种是独立建设新业务线,导致各业务线之间存在大量重复代码,带来重复建设和多头维护问题,效率低下。该网关负责处理通用的系统级功能,包括通信协议适配、前台要快,后台要稳,导致业务扩展时面临两类挑战: - 营销思路变动快,前台易改,但后台调整耗时,影响面广,成本高;
- 后台系统老旧、
优点之一是简单便利。系统运营能力(例如监控、不同的项目和组织可能面临不同的挑战,因此根据实际情况调整微服务架构的实施策略。 第二种是通过抽取各业务线中相同的核心逻辑,实现通用化,构建一个“山”字型的系统结构,其中上面三竖代表各业务线的定制应用,底下一横代表通用层,实现了业务逻辑和规则的统一。中台通过收敛业务场景和规则、
| 技术创新 | 注重技术创新和工程实践,采用最新的技术架构和开发模式。 典型的传统企业中台架构设计如下: 
整个中台架构从上到下分为四个层次: 渠道&应用渠道&应用层,这是整个系统的对外部分,包括了各个应用的前端,如App、通过实现标准化的业务逻辑,通用基础业务平台确保了业务的一致性和可靠性。监控、在数字化转型的浪潮中,1号店通过引入微服务架构,成功地将各个业务模块独立化,优化了资源的利用效率。在单体架构中,通过构建清晰的模块体系来支持系统的扩展变得困难。顺风车等。 其次,SOA服务不依附于特定应用,具有独立的部署和扩展性,避免了对现有系统的直接影响,提高了系统的灵活性。(一)V1.0架构首先,让我们聊一下1.0版本。详情页服务、多处复用,一处修改、 通用聚合服务的设计注重易用性和可组合性,使得业务开发者能够更加专注于业务本身,而不必过于关注底层基础服务的复杂性。App前端的外包团队只需与一个移动团队对接,通过现有的Jar包封装各业务线功能。稳定和灵活的业务支持。 
可以深入了解中台的三个关键组成部分,以及它们如何协同工作,提供全方位的支持: 通用基础业务平台这一层承担了实现核心业务能力的责任。开发、订单管理等,这些服务是整个企业业务中不同模块通用的基础构建块。分析等服务,构建企业级的数据湖,支持业务和决策需求。 举个淘宝的例子,淘宝的系统基本是自建的,系统相互打通的问题不大。而新的SOA架构,它利用服务共享的思想,解决系统的重复开发问题。通过这一层的存在,业务中台得以在迅速变化的市场中保持稳定,有效地应对各种挑战。需要注意的是,中台不仅仅是前后台之间的简单适配器,它本身会落地业务数据,具备完整的业务规则。 
这个1.0版本的服务端本质上是一个单体应用,只是外部接口和内部Jar包分别由不同的团队提供。共享数据可能导致微服务之间的依赖性增加。性能强化)以及业务运营能力(例如商品中心自带配套的商品管理后台)。同时,水平扩展和垂直扩展是两种常见的扩展策略,前者通过增加节点或服务器来分担负载,后者则通过提升单节点性能来处理更多请求。一方面,每个移动端接口需要调用对应的后台服务,进行个性化的业务逻辑处理;另一方面,每个移动端接口都需要进行系统级的功能处理,如安全验证、 | 开发中台 (Development) | 提升开发效率和协作方式 | 提供开发工具、从某种程度上说,微服务可以被称为微应用或微产品,是对分布式架构拆分得更细的一种实践。团队组织和沟通:跨职能团队的构建和协作是微服务成功实施的关键。一个PC端Web应用,以及一个负责维护和部署核心业务逻辑的服务。确保团队理解微服务的理念,并能够有效地沟通和协同工作。 新的SOA架构如下图所示: 特点 | 传统SOA架构 | 新SOA架构 |
---|
应用场景 | 主要用于解决系统集成问题 | 解决系统的重复开发问题,服务共享思想 | 核心思想 | 面向服务 | 以服务共享为核心思想 | 解决问题 | 解决异构系统集成问题 | 提高系统扩展能力,避免重复开发 | 服务特点 | 面向系统功能,较为粗粒度 | 面向通用逻辑和数据,提供给多个业务系统共享 | 目标效果 | 打通信息孤岛,解决企业内部系统通信问题 | 提高系统开发效率、稳定性、 这些问题的根本原因在于在App端直接采用了PC端的做法,没有根据移动端自身特点进行架构设计。订单服务等。该架构的核心理念是面向服务,通过清晰的服务接口解决了技术异构性,使得不同系统能够协同工作。 这三者的协同工作使得中台不仅仅是业务线的集合,更是一个有机整体,为企业提供了高效、文化和组织变革。 (三)V3.0架构
在V3.0版本的服务端架构中,经历了两个主要的升级。为满足移动端需求,他们在Web应用中增加了一些REST接口,供App访问。简化和标准化。新SOA架构在强调服务共享和解决系统重复开发问题方面具有明显优势。写入、 然而,值得注意的是,尽管SOA服务化的思想带来了这些优势,但在实际系统实现上可能面临一些挑战,包括架构的复杂性、因此,中台可以先承接前台的业务和数据,与前台构成C端业务的小闭环,支持快速创新。 二、因此,随着App的发展,架构需要根据各自不同的特点进行演变。第二部分是企业内部系统,这个是企业的IT基础设施,业务最终会在这里落地。在传统的微服务体系下,我们构建了一系列离散的服务,如商品服务、前台通常追求快速创新,而后台则注重稳定性。当我们深入了解业务中台时,可以看到它通常包含三个层次,从上到下分别是通用聚合服务层、店铺、对于这些挑战需要认真思考和妥善解决。微服务的团队成员跨职能,包括产品、 通用聚合服务层这一层通过对基础业务的巧妙组合,提供更高层次的抽象和更丰富的业务能力。通过对这一转型过程的深入分析,我们将揭示可扩展性架构设计的核心原则,帮助电商平台在竞争激烈的市场中立于不败之地。 另一方面,与业务线的相似度有关,相似度越高,更适合“山”字型。采用服务化架构,将系统拆解成小型服务单元,有助于独立开发和扩展。App服务端等等,这些服务端会针对具体场景,做流程编排和信息的聚合。微服务的松散性逐渐演变为共享服务体系,最终形成中台,这是微服务架构向中台架构的自然演进。但经过一段时间的自然生长,系统重复建设的问题很突出,前面也提到,有超过1/3的核心代码重复。找到适度的拆分粒度,使得每个微服务可以独立开发和部署,同时保持整体系统的可维护性。 |
(三)SOA架构传统SOA架构起源于企业信息化建设高潮,解决了不同供应商提供的系统之间的集成问题。例如,企业内部的管理系统,服务于不同的职能部门,如财务系统和HR系统,按照分布式架构实现更为合适。这样的设计使得业务线能够更加敏捷地应对市场需求变化,降低了开发的复杂度。面对这种情况,有两种处理方式。保持开放的沟通以及建立高效的反馈机制,以确保每一步都能顺利推进。库存、安全管理等服务,确保中台系统的稳定运行。为解决这一问题,中台架构应运而生,旨在实现前后台平滑对接。 三、(四)微服务架构在微服务架构中,每个微服务都负责端到端的业务,包括前端UI展示和后端业务逻辑。 代码都放在一个代码库里管理,当多团队并行开发时容易发生代码冲突,这进一步阻碍了系统的快速扩展。 | 基础服务强化 | 强化现有基础服务,提升性能、 其中的基础数据模型、由于移动团队和业务团队通过物理Jar包集成,移动团队直接受到业务团队代码的影响,导致团队之间难以并行开发。运维等,负责整个服务的生命周期管理。在这种架构下,所有代码运行在一个进程中,而所有的数据通常存储在一个数据库中。 | 适用场景 | 适用于业务相关性低、总结 通过1号店的案例,我们清晰地看到了从单体架构到微服务架构转型的必要性和实施过程。 因此,微服务兼有应用和服务的特征,可以被理解为: 微服务 = 小应用 + 小服务。这使得微服务提供方能够自由选择语言和工具来实现微服务,使得服务的部署和维护更加灵活。中台的定位在于作为前后台之间的衔接层,既支持业务的灵活发展,又确保整体系统的稳定性。清洗、 应用平台应用平台是各个具体应用的母体,它包含了各个应用的服务端,比如小程序服务端、这对于频繁部署和快速反馈是至关重要的。 
在微服务架构的实践中,有一些经验和教训是值得注意的: 经验:
|
|
|
|