精华内容
下载资源
问答
  • 中台组织结构设计
    千次阅读
    2019-04-23 11:01:41

    分享一个大神的人工智能教程。零基础!通俗易懂!风趣幽默!还带黄段子!希望你也加入到人工智能的队伍中来!点击浏览教程

    一、什么是“大中台、小前台”

    关键词:精准打击、管理高效、资源整合、灵活敏捷

    阿里巴巴 “大中台、小前台”机制的提出,某种程度上是从传统的事业部制向准事业部制的转换。就阿里巴巴而言,“前台”就是贴近最终用户/商家的业务部门,包括零售电商、广告业务、云计算、物流以及其它创新业务等;而“中台”则是强调资源整合、能力沉淀的平台体系,为“前台”的业务开展提供底层的技术、数据等资源和能力的支持,中台将集合整个集团的运营数据能力、产品技术能力,对各前台业务形成强力支撑

    前台和中台本质上是工作分工的问题。比如,某部门要开发一款App,是部门内部(大前台)自己组织一套技术、产品、设计、运营的团队,还是集团为其提供资源(大中台),由专门的技术团队来帮助其开发、设计产品等等。

    所以说, “小前台+大中台”的运营模式,就是美军的“特种部队(小前台)+航母舰群(大中台)”

    更多相关内容
  • 中台架构设计

    千次阅读 2022-01-26 11:26:18
    中台架构的主要目标是通过业务领域边界划分和微服务拆分,建立稳定的、单一职责的领域模型,让业务和应用具有更强的扩展和复用能力。

    1 中台架构

    1.1 双中台模式

    在这里插入图片描述

    数据已经成为企业级服务能力的标配,所以中台一般包括业务中台、数据中台两部分。

    中台架构的主要目标是通过业务领域边界划分和微服务拆分,建立稳定的、单一职责的领域模型,让业务和应用具有更强的扩展和复用能力。在业务拆分完毕以后,我们需要对这些拆分的、稳定的、单一职责的领域能力进行组合、编排、融合,从而灵活快速的适配外部业务。例如:电商平台的中台可以包括数十个微服务,但是对于用户而言,从商品浏览、加购物车、下单、支付、查看订单信息等是一个完整的业务流程,对用户而言就是一体的。

    1.2 DDD VS 中台 VS 微服务

    在这里插入图片描述

    • 中台架构
      中台的本质是提炼各个业务板块的共同需求,进行业务和系统抽象,形成通用的、可服用的业务模型,打造组件化产品,供前台部门使用。
      中台形成的过程实际上是业务领域不断细分和功能不断沉淀,在这个过程中根据界限上下文、业务内聚的原则,落地成各个领域的微服务;具有共用服务能力的微服务聚合在一起就形成业务中台。

    • DDD
      DDD本质是按照一定的规则将业务领域进行细分,将要解决的问题限定在边界内,在这个边界内构建领域模型。

    • 微服务
      将领域内要解决的问题落地后就是微服务,一般和系统对应。

    2 设计原则

    2.1 系统设计原则

    • 稳定性原则
      核心服务、非核心服务要分离;给核心服务足够的buffer、严谨性以确保系统稳定可靠。
      系统的实现不能有单点。
      系统要做到无状态,无状态的服务是可伸缩、高可用性的基础。
    • 模块原则
      同一个领域业务,不要放到多个系统中。多个领域的业务尽量不要混在一起,通过包、模块或系统分开。
    • 防腐原则
      隔离服务内部的变化原则:对外提供服务、消费他人服务时,在领域层外要加一层防腐层,隔离外部变化对当前系统的影响,也防止当前系统升级对上游的影响。
    • 冗余性原则
      实体、模型中减少字段冗余,尽量实时查询,否则数据不一致会变成大坑。
      注意:单据类型的实体,一般来说必须冗余,因为单据落地哪一个数据就不会再变了。

    2.2 依赖&调用原则

    • 服务依赖原则
      重要的服务不能依赖非重要服务。
      上可依赖下,下不可依赖上;上可跨级依赖下。
      平级可允许单向调用。
      坚决禁止循环依赖,上游通过RPC调用下游,下游通过MQ通知上游。

    • 服务调用原则
      服务调用都要设定超时时间。
      遵循fast-fail原则,避免服务调用时间过长,导致性能下降。fast-fail原则是只要发生错误,则调用立即返回。
      服务的调用结果只有三种可能:成功、失败或未知。
      能异步调用的服务尽量使用异步调用;提高系统响应速度,降低系统之间的耦合性。

    2.3 接口设计原则

    • 命名原则
      系统、接口、方法、实体等命名要具有业务含义;使用名词命名服务,使用动词命名操作;看到名字就应该能大概知道其负责的内容。
    • 开闭原则
      服务要能够向下兼容,不能随便修改或重构,务必遵守开闭原则。
    • 抽象&通用原则
      提供通用型接口:接口尽量具有通用性,不要为每一个场景设计一个接口。尽可能让服务消费方根据自己的需要组合接口数据;否则时间久了系统接口维护起来很崩溃。
      接口粒度原则:一个接口应该拥有独立且完整的功能,尽量避免多个接口组合起来完成一个操作;最好对应前端一个功能,或者一个用例;对外尽可能避免提供零散的接口。
    • 接口耦合原则
      面向接口编程是基本要求。要面向接口编程,不能面向实现编程。
    • 接口先行原则
      详细规定服务与客户端双方对接的内容与形式等,对双方形成强有力的约束和保障。

    2.4 其他原则

    静态资源与动态资源分离,从而提高性能。
    所有请求都应该有日志,日志要能反映调用链路。
    方法入口、出口测最好都有日志,方便定位问题。

    3 实践

    3.1 中台架构图

    在这里插入图片描述

    这是目前我们使用的系统架构。

    • 应用
      这是我们对外提供服务的站点,对外提供完整的解决方案。这些服务他们使用同一套业务中台、数据中台,在经过前端的编排、组合后,对用户提供完善的服务。

    • 中台

      • 业务中台
        包括了公司的核心业务领域,沉淀了公司核心的业务流程。
      • 数据中台
        包含了对数据的采集、清洗、计算等业务,数据从业务中台来,同时服务于业务中台。
      • 风控中心
        一般而言风控也属于业务中台的一部分,不过他更多起到的是辅助业务、安全防护的目的,防止业务失控,对公司造成损失。一般而言和数据中台交互比较深入。
      • 辅助业务模块
        起辅助作用,让业务、数据中台关注自己领域内的核心业务。例如:任务系统、日志平台等。
      • 分布式中间件
        深入中台服务的各个角落,帮助中台做好自己领域职责。
    • 基础设置
      偏运维,用户管理容器、服务器、代码等。

    3.2 业务中台

    将业务中台拆解后,各个微服务的交互如下图所示:
    在这里插入图片描述

    • 网关
      API网关针对内部服务提供API接口;开封平台针对外部公司提供服务能力。

    • 业务

      • 平台型业务领域
        指的是电商平台、撮合平台。公司作为平台方,撮合买卖双方达成交易,并为交易提供履约和担保。
      • SaaS型业务领域
        指的是ERP服务,需要帮助客户管理其采销存、钱货票。
      • 通用型业务领域
        平台型业务和SaaS型业务他们有很多差异,例如:SaaS关注的是一个公司的经营活动管理,平台型业务更多关注交易、履约等;他们也有很多相似性,例如都需要物流、发票、费用等领域。在项目进行领域拆分、边界划分的时候就要考虑好那些服务是通用型的,那些是某个业务个性化的,将通用的服务沉淀到底层,避免重复造轮子。
      • 基础业务领域
        属于业务领域的范畴,为所有业务领域提供服务的领域。例如:短信服务、IM服务,一般来说任何业务都可能会用到他们,这些服务中可以是抽象的、共用的,甚至不同公司这些服务基本都相同。
      • 基础领域
        不属于业务范畴,为所有业务领域提供服务的领域。例如:Id生成器为所有系统提供生成id的能力。
    • 风控领域
      围绕数据和业务,为业务保驾护航。根据业务规则,抽象风控规则;将风控规则、业务数据传递给风控引擎进行计算,判定业务是否安全。

    • 业务辅助领域
      起辅助作用,让业务中台关注自己领域内的核心业务。例如:很多时候业务经常需要在某一个时间点触发某些任务,而任务的执行又要考虑失败重试、任务降级等内容,超时系统就可以将所有失败重试、任务降级、执行时间、执行结果等功能涵盖,并在准确的时间点触发业务执行对应的逻辑。

    4 中台建设

    4.1 企业是否需要中台

    • 是否大型复杂生态系统
      企业业务简单、团队规模较小时不太适合中台架构。
    • 是否业务具备不确定性
      市场环境变化快,如互联网行业、产业互联网等相关行业,都属于这类型行业。
    • 是否存在大量重复建设
      重复建设多的系统,系统维护成本高、迭代速度慢,也更容易出现故障。
    • 是否存在数据互联互通问题
      由于事业部制的组织架构,形成了部门墙,数据和系统也是烟囱式的,中台架构比较适合这种公司。
    • 是否信息技术制约企业发展
      项目迭代速度慢,制约业务发展;新业务建设难、复杂度高,制约企业发展,等等。

    任意满足3个及以上,适合做中台战略升级;否则需要保持谨慎,因为中台架构的开发成本、系统复杂性都会较高。

    4.2 中台注意事项

    • 中台架构
      中台架构的目标:通过技术的抽象和沉淀,让企业降低成本,提升协作效率,加快迭代速度。
      中台架构是一套方法论,解决复杂、多变业务的方法论,不能奢望中台架构能包治百病。

    • 组织架构匹配
      中台的目标是将业务做抽象和沉淀,服务于集团所有业务;而实际中每个团队的业务、目标不同,很容易造成重复造轮子的事情。如果组织架构不匹配,中台建设中会有很多阻力。

    • 团队能力匹配
      团队中应该有架构师能把控各个服务的领域边界,让相同领域的服务沉淀到一个系统中;团队成员要能面向领域开发,而不是面向数据库开发;产品也应该具有抽象能力,产品、研发一起共建中台,避免业务之间复杂的相互纠缠。
      其实:DDD的战略设计落地的过程就是中台架构落地的过程。

    5 参考文档

    《中台架构与实践-基于DDD和微服务》

    中台战略:业务中台的8个设计原则

    中台研究(一):阿里的“数据+业务”双中台架构

    展开全文
  • 结构施工组织设计-河北石家庄某电视工程桩基(钻孔灌注桩)施工组织设计方案
  • 数据中台02:数据中台架构

    千次阅读 2022-03-17 12:48:38
    前面我们通过理论层面对数据中台有了一定的了解,下面我们通过架构层面来详细看一下数据中台设计。 数据中台是位于底层存储计算平台与上层的数据应用之间的一整套体系。 数据中台屏蔽掉底层存储平台的计算技术...

    一、数据中台总体架构图

    前面我们通过理论层面对数据中台有了一定的了解,下面我们通过架构层面来详细看一下数据中台的设计。

    在这里插入图片描述

    数据中台是位于底层存储计算平台与上层的数据应用之间的一整套体系。

    数据中台屏蔽掉底层存储平台的计算技术复杂性,降低对技术人才的需求,让数据的使用成本更低。

    通过数据中台的数据汇聚、数据开发模块建立企业数据资产。

    通过数据体系对数据进行分层存储

    通过资产管理、数据服务,把数据资产变为数据服务能力,服务于企业业务。

    数据安全管理、数据运营体系,保障数据中台可以长期健康、持续运转。

    1、数据汇聚

    数据汇聚是数据中台数据接入的入口,数据中台本身不产生数据,所有的数据来自于业务系统,数据库、日志、文件等,这些数据分散在不同的网络环境和存储平台中,难以利用,很难产生业务价值,所以需要统一汇聚。

    2、数据开发

    数据开发是一整套数据加工以及处理的工具,因为通过数据汇聚模块汇聚到中台的数据没有经过处理,基本是按照数据的原始状态堆砌在一起的,这样业务是很难直接使用的。所以需要通过数据开发模块实现对数据的加工处理,形成有价值的数据,提供给业务部门使用。

    3、数据体系

    通过数据汇聚、数据开发,中台就具备了构建数仓平台的基本能力,这一块其实就是将采集过来的各种数据按照数仓的标准进行建设。

    4、数据资产管理

    通过数仓建立起来的数据资产比较偏向于技术,业务人员比较难理解,资产管理是以业务人员更好理解的方式,把数据资产展现给企业的业务人员。

    5、数据服务体系

    数据服务体系就是把数据变为一种服务能力,通过数据服务让数据参与到业务,激活整个数据中台,数据服务体系是数据中台存在的价值所在。

    6、数据运营体系

    是数据中台得以健康、持续运转的基础

    7、数据安全管理

    是为了保证数据中台中的数据安全。

    这是一个典型的数据中台总体架构设计。

    二、数据中台 四字箴言

    如果大家之前没有工作过的话,可能对数据中台还是不好理解,所以在这我将数据中台的功能总结为四个字:采、存、通、用

    在这里插入图片描述
    下面我们来详细分析一下这四字箴言

    1、采

    采:表示采集的意思,就是采集企业中的所有数据。

    随着互联网、移动互联网、物联网等技术的兴起,企业的业务形态开始多元化,数据的产生形式也是多样化的,对应的就需要有多种采集形式。

    埋点采集、硬件采集、爬虫采集、数据库采集、日志采集。

    埋点采集:一般是采集用户行为信息,例如用户在平台上的浏览、点击、停留等行为。

    硬件采集:指的是物联网数据采集,例如通过无人机传感器来采集空气质量指标。

    爬虫采集:指的是采集互联网上的公开数据,例如:电商平台竞品价格采集。

    数据库采集:一般是采集企业内的业务数据,例如:用户交易数据、用户个人信息数据等。

    日志采集:一般是采集软件运行时产生的日志。

    这些是常见的采集形式。

    从数据组织形式可以分为:结构化数据、半结构化数据、非结构化数据。

    结构化数据:数据规则、完整、能够通过二维逻辑来表现的数据,严格遵守数据格式与长度规范,常见的有数据库中的数据、excel中的数据。

    半结构化数据:数据规则、完整,同样严格遵守数据格式与长度规范,但无法通过二维关系来表现,常见的有JSON、XML等格式的数据。

    非结构化数据:数据结构不规则或不完整,不方便用二维逻辑表来表现,需要经过复杂的逻辑处理才能提取其中的信息内容,常见的有word文档、图片、视频、音频等数据。

    从数据的时效性上来划分,可以分为:离线数据、实时数据。

    离线数据:主要用于大批量数据的周期性迁移,对时效性要求不高,一般采用分布式批量数据同步的形式,通过连接读取数据,读取数据过程中可以有全量、增量的方式,经过统一处理后写入到目标存储。

    实时数据:主要面向低延时的数据应用场景,一般通过实时监控的方式实现,例如通过读取数据库的binlog日志来实现数据库的实时数据采集。

    前面我们针对数据的采集形式、数据的组织形式、数据的时效性进行了分析,那这些数据在采集的时候具体应该使用什么类型的工具呢?

    常见的采集工具有:Flume、FileBeat、Logstash、Sqoop、Canal、DataX等。

    其中Flume、FileBeat、Logstash适合采集日志数据,这三个组件的特性在前面项目课程中已经详细分析过了,在这不再赘述。

    sqoop是在结构化数据和HDFS之间进行批量数据迁移的工具,适合批量采集数据库中的数据,它的主要优势是,在特定场景下,数据交换过程会有很大的性能提升。主要缺点是处理过程定制程度较高,需要在脚本中调整配置参数实现,在用户的一些自定义逻辑和数据同步链路监控方面比较薄弱。

    DataX是阿里开源的一套数据采集工具,提供数据采集全链路的流量监控,将作业本身的状态,数据流量,数据速度,执行速度等信息进行展示,提供脏数据探测功能,支持传输过程中对传输报错进行策略化处理。

    由于它是基于进程内读写直连的方式,高并发数据采集场景下对机器内存要求比较高。
    不过DataX不支持非结构化数据的采集。

    这些单个工具都无法很好的满足企业复杂的数据采集场景,所以我们需要对已有的采集工具进行二次开发,以可视化配置的方式提供给用户,屏蔽底层工具的复杂性,要支持常见的数据源采集:关系型数据库、NoSQL数据库、MQ、文件系统等,并且支持增量同步、全量同步等方式。

    2、存

    将数据采集过来之后,就需要考虑数据存储了。

    在这里我们可以将数据分为两种:静态数据和动态数据。

    其中静态数据:是以 HDFS 、S3等分布式文件系统作为存储引擎,适用于高吞吐量的离线大数据分析场景。这类存储的局限性是数据无法进行随机的读写。

    动态数据:是以 HBase、Cassandra等NoSQL数据库作为存储引擎,适用于大数据随机读写的场景。这类存储的局限性是批量读取吞吐量远不如 HDFS,不适合用于批量数据分析的场景。

    3、通

    表示是对数据进行加工计算,构建企业级数据仓库,打通企业中的全域数据。

    针对数据的加工计算,可以分为两大块,离线计算和实时计算。

    离线计算中的代表框架为:MapReduce、Hive、和Spark。

    实时计算中的代表框架为:Storm、SparkStreaming和Flink,针对实时计算,现在主要是以Flink为主了。

    针对这些计算框架,如果每一个计算任务都需要开发代码的话,对使用人员就不友好了,特别是针对一些业务人员,他们不会写代码,只会写SQL,所以这时候我们就需要开发一套基于SQL的一站式开发平台,底层引擎使用Spark和Flink,支持离线数据计算和实时数据计算。
    让用户彻底规避掉繁重的底层代码开发工作。

    4、用

    企业全域数据采集、存储,打通之后,就涉及到如何去用了。
    这里的”用” 包含很多层面。

    首先是包括数据资产管理,也可以称之为数据治理,其中包含数据元标准管理,数据标签管理,数据模型管理、元数据管理、数据质量管理等,保证数据中台里面数据的合理化和规范化,充分发挥数据的价值。

    对于数据的拥有者和管理者来说,通过对数据的合理管理和有效应用,能盘活并充分释放数据的巨大价值,但如果不能对数据进行有效管理,数据就用不起来,或者即使用起来也用不好,在这种情况下,堆积如山的无序数据给企业带来的是高昂的成本。

    在使用数据的时候还需要做好数据安全管理,随着大数据技术和应用的快速发展,数据所承载的多维度业务价值已被越来越多的挖掘和应用变现,随之而来的是数据安全和隐私已经成为世界性的关注点,上升到国家战略层面,最近闹得沸沸扬扬的特朗普要禁用国外版的抖音(TikTok)事件,特朗普的理由就是TikTok平台的数据对他们产生了威胁。

    所以说数据安全很有必要,整体的数据安全管理体系通过分层建设、分级防护,创造面向数据的安全管理体系系统框架,形成完整的数据安全管理体系。

    数据中台的建设,应该始终把数据安全管理放在最重要的位置上,通过设计完备的数据安全管理体系,多方面,多层次保障数据安全。

    最终我们需要把安全、有价值的数据快速方便的提供给上层应用,此时需要通过数据服务对外开放,也就是API接口的形式。

    举个例子,水是生命之源,是人们赖以生存和发展的重要物质资源,在日常生活中,可以通过不同的方式使用水,这也给我们的生活带来了巨大便利。

    在数据世界中,数据资产就好比日常生活中生命所需的水资源,无处不在且不可或缺。但是如果没有相应的水加工厂,运输管道,人们只能到水库打水喝,这明显会极大影响人们正常的生活和工作。因此,将数据封装成数据服务,以接口形式提供给上层应用,才能极大释放、提升数据资产的价值。

    最后总结一下,数据中台其实可以这样理解,采集企业全域数据,存储起来,通过加工计算打通数据之间的关系,最后以API接口的形式对外提供数据服务。这就是数据中台要做的事情。

    展开全文
  • 业务中台总体架构介绍与交易业务中台核心设计架构总原则:电商中台:服务接入层:公用基础组件:云服务&设施容器层业务前台产品:稳定和安全保障系统工程结构: 架构总原则: 大中+小前台的架构思路 业务中台...

    架构总原则:

    大中台+小前台的架构思路

    业务中台采用领域驱动设计(DDD),在其上构建业务能力SAAS,持续不断进行迭代演进。

    平台化定位,进行了业务隔离设计,方便一套系统支撑不同玩法的业务类型和便于定制化扩展。

    前后端分离,通过服务接入层进行路由适配转发。

    天然的分库分表,消息解耦和分布式缓存设计,支持弹性扩容,以支持大数据高并发场景。

    系统逻辑架构图:
    在这里插入图片描述
    接下来将分别介绍每个部分。

    电商中台:

    中台部分在逻辑上分成了基础能力和平台产品两层,这样做的好处是,基础能力层聚焦于稳定收敛的业务模型和基础服务本身,不会随着业务和前台产品的调整发生变化,可以简单理解为业务模型的DAO。平台产品层则专注于通过流程编排类的技术手段,将基础能力构建成业务的解决方案,解决共性和个性化的问题。我们将以交易的设计为例来说明这个分层理念。通过对电商交易业务的深入分析,

    可以确定几乎所有的交易都会涉及下图中所有的领域(库存,优惠,价格…),而单看每个域,玩法都是很少变化的,将这些域的基础能力完全可以沉淀下来形成原子的基础能力,通过扩展点方式应对将来特殊的场景个性化扩展。
    在这里插入图片描述
    平台产品层为了应对不同的交易场景(一口价,拍卖,货到付款,预售…)将原子的基础能力编排成满足不同场景的解决方案,以服务的方式透出出去。
    在这里插入图片描述

    服务接入层:

    服务接入层是连接前台产品和中台产品层的纽带, 实质就是之前的web 应用,不同的是现在前后端分离后,只包含java 代码,使用springBoot web。做参数转换,路由分发,调用中台服务,结果封装。这块需要做好前后端的交互规范,请求路由映射规范,web工程目录结构,负载均衡方案,跨越问题和安全问题,

    后续会有专题详细介绍这块。

    公用基础组件:

    沉淀和抽象出通用独立的公共基础组件,这些组件在服务本项目,本团队的同时,可以开源出去服务更多的人; 抽几个非常重要的组件讲一下这么做的目的。

    数据访问组件: 抽象封装分库分表访问,读写分离,主备切换。

    消息中间件组件:这块的选择非常多,就开源的就有activeMQ,RabbitMQ,RocketMQ,Kafka等等, 再加上阿里云,AWS, 腾讯云等提供的和对应的云版本,会非常多,如果不对这块做封装,对其上应用做透明化处理,后期做这块的适配调整就会非常痛苦,特别是这套系统会在不同环境中进行部署时。

    地址库组件: 统一地理地址相关的服务,如果是有拓展国际市场的需求,这块会显得的非常重要,不同文化背景的国家,在这块的差异会非常大,同时国内也涉及3级,4级和5级地址的问题。

    云服务&设施容器层

    如果技术团队不是非常大,又没有较强的运维技术人员,建议不要购买物理机自己搭建环境,而是直接使用阿里云这些比较成熟的ECS和其他云服务,这样会节省很多时间成本和一些耗时的运维工作,让其专注于业务产品的研发,同时使用docker 容器部署应用,不仅需要的机器数量比较少而且部署非常便捷高效。

    业务前台产品:

    ios ,android APP , H5 APP ,PC 站点,微信支付宝小程序 都是属于这层,前台产品主要是根据业务形态和产品的定位来进行构建。对于电商业务来说,主要是指移动APP商城,H5商城,PC商城 ,小程序商城。将以小程序为例来说明。

    为了适应小程序,社交电商这样的热点,加上有这么优秀的一套电商中台系统,不搞出点有么有样的电商前台产品,不是很没有道理,为此想破脑袋,我们把电商和送礼结合了起来,做了“礼尚往来”的小程序,下面是产品的截图。
    在这里插入图片描述

    稳定和安全保障系统

    对电商这类在线交易系统,流量会随着运营活动的波动非常大,特别是到了双11这类大活动的时候,流量的峰值会是平时的几十~几百倍,一些接口会放大的更大;核心系统的系统指标,流量,接口调用量和rt, 以及限流和异常的监控就显得非常重要了。在几年之前,只有BAT 几个大的公司有能力在这方面做的不错,随着全民参与的这种大型促销活动推动技术的进步,以及开源社区和一些大厂将类似方案回馈到开源社区,目前一个小的技术团队做好这块也没有什么难度了。现将我们用到的框架做个简单的介绍,更多细节请参考官方文档。

    sentinel:是面向分布式服务架构的轻量级流量控制产品,主要以流量为切入点,从流量控制、熔断降级、系统负载保护等多个维度来帮助您保护服务的稳定性。 该系统已经过阿里内部双11多年的验证,稳定性和可靠性非常不错,已于最近开源。

    dubbokeeper: dubbo的官方监控dubbo-monitor-simple 在性能上表现非常不好,经常卡死,对比了几个成熟的框架后,最终确定使用dubbokeeper. dubbokeeper社区版dubboadmin,包括了应用管理,动态配置,统计信息,服务监控和zk信息查看功能。

    pinpoint: 现在基于微服务的架构,一个请求从用户发起到响应,中间调用链路非常长,跨越数十个系统很正常,并且路径非常多,要定位一个比较耗时的响应,不利用工具,是非常低效的。Pinpoint这样的工具就是为处理这个问题出现的,Pinpoint的优点是对代码零侵入,运用JavaAgent字节码增强技术,追踪每个请求的完整调用链路。

    Telegraf+ influxDB+ Grafana:主要用来实现业务数据的实时监控方案,如交易额的不正常波动,订单量的突然下跌等。Telegraf 是收集数据的代理程序,可以根据业务需要添加插件扩展服务,收集到的数据写入分布式时序数据库influxDB,再通过grafana 可视化的展示出来。

    工程结构:

    逻辑结构映射到物理的工程结构,每个逻辑单元对应为一个子工程,如果是用idea 开发,就是一个model, 当然model 里边会有子model;至于需要打包构建多少个系统其决定性因素是你团队的规模,如果团队规模较少,中台系统合并到3-4个左右就足够了,如果团非常大,一个团队负责一个业务板块的,并为其构建多个系统,也是非常正常的,像较大的电商公司,负责商品的就是一个团队,商品相关的系统就有数10个。以交易为例,可以将交易的系统合并为一个系统,但在工程的组织结构上是对立的,方便将来的拆分。
    在这里插入图片描述
    为什么要用业务中台化思想来架构交易系统

    上面介绍了交易业务中台的设计理念,本篇会详细的来说为何要用中台的思想来架构交易系统。要说明白这个问题,我们必须回看系统的演化路径是怎样随着业务规模的增长进行变化的。

    首先来看初创公司/新业务系统是如何演进的;以基于云计算为基础的架构模式,大部分的初创的系统架构图如下
    在这里插入图片描述
    对于一个业务规模很小,业务也比较单一,该架构也是最高效的方式,一到两个web系统,数个微服务业务系统,一到两个前台系统。微服务业务系统将会把会员,商品,类目,店铺,交易,库存,物流这些划分成不同的模块/包放在一到几个系统,这样做的好处是非常明显的,每个人都熟悉所有的代码,代码量不大,开发效率高,这在公司刚起步时,是非常接地气的和最适合的架构。

    随着公司业务规模和组织的壮大,会基于上面的架构,迭代演进N次,直到系统不再是制约公司发展的瓶颈,这期间最重要的架构升级是系统和数据库的垂直拆分,异步消息解耦,分布式事务机制,稳定性保障。为了快速说明问题,我们将忽略中间演进版本,直通基于中台的版本。

    在介绍业务中台模式之前,先来看看中台概念的产生背景,中台研发模式最早产生于芬兰著名游戏公司supercell. Supercell有员工180人,后被腾讯以100亿美金估值收购,其鼎峰时期全球排名top10的游戏,有5个来自supercell, 其能快速推出高质量的游戏,其大中台功不可没。阿里借鉴了supercell的“大中台,小前台”的模式,以解决快速创新试错的前端业务和日益沉重的淘宝天猫这些核心系统之间的矛盾,以提升研发效率和跨团队合作。

    可以进一步的设想,如果公司业务高速发展,特别是互联网的业务模式,出现10倍增速的发展也很正常,这会面临业务和技术团队规模变大,业务也会越来越复杂,就以交易为例,最初就是简单支撑实物购买场景(消费者付款购买,平台/商家发货),随着用户和业务的发展,会出现,虚拟商品交易,团购,拼团,拍卖,秒杀,预售等等交易业务模式。
    在这里插入图片描述
    最初就是一个系统单纯的支持一个单一的业务,到了阶段二支持三个业务,你还能勉强活着,到了阶段三如果还是使用之前的架构和开发模式,你会陷入泥潭,在阶段三必然会出现以下问题:

    [if !supportLists]1.[endif]业务之间的需求相互影响,修改和测试回归成本非常高,但还是会发生意想不到的线上问题。

    [if !supportLists]2.[endif]由于支撑的需求越来越多,没有人能掌控全局,修改无存下手,开发越来越不敢接需求。

    [if !supportLists]3.[endif]多个需求并行的开发是场噩梦,团队经常加班,还是满足不了业务需求的开发,团队越来越是瓶颈,经常接到业务方的投诉。

    业务中台化也就是解决这些问题的最佳选择,将交易域的核心能力和服务,通过梳理抽象沉淀为稳定外化的服务,通过预留的扩展点,来支持个性化扩展。扩展点的开发完全可以由业务团队的技术来进行,交易中台研发将专注于中台的建设和稳定性,这样讲大大改善开发协作效率,一个业务能不能跑的快,主要依赖于前台,当然业务中台的技术团队需要做好业务隔离和中台本身的稳定高效进化。

    了解交易的一般业务流程

    本篇是用来讲交易的,结果扯了太多业务中台的东西,现在直奔交易,看看交易的两个业务流程。

    交易订单创建流程:
    在这里插入图片描述
    简化的逆向退款流程:

    在这里插入图片描述
    只举例2个业务流程,其他的大同小异,对交易业务的分析和梳理,不难发现,交易涉及的业务域可以归类为以下几个方面:价格,优惠,库存,拆单,支付,限购,交付,订单,超时,售后。

    交易业务中台架构

    通过对交易业务流程和业务的分析和梳理,采用20/80原则,可以建模抽象出基础能力层

    在这里插入图片描述
    交易是很多契约的组合体,基础能力服务是最原子性的,还需要将这些通过流程编排组合成有业务价值的交易产品来统一对外输出和管理,这就是交易平台产品层的职责,解决共性和差异性的问题。

    业务中台总体架构介绍与交易业务中台核心设计
    在这里插入图片描述
    此外交易系统需要依赖会员,商品,店铺,库存,优惠,支付和物流等这样的业务服务才能完成一个真正的交易,加上这些我们基本可以确定交易的业务中台架构图,如下:
    在这里插入图片描述
    有了整体的全局大图,接下来我们将会按照如下的框架来详细介绍每个部分。
    在这里插入图片描述
    总体设计:

    核心业务领域模型:

    领域模型的设计,还是遵守DDD的原则,这块做的好坏,关键是对这块业务的理解和未来一段时间的预判,加上抽象归纳。
    在这里插入图片描述
    核心类图:

    从总体设计的角度看,总体的类图应当是关注业务模型本身,按照之前约定,我们先看BA层的业务模型
    在这里插入图片描述
    这个类图,只画了宏观和重要的业务域类,其他用来支撑的类图,将在BA层做展示,目前帮助理解交易这些类图足够说明问题,太多反而没有重点。

    PA层是对外开放的服务层,按照惯例设计,会有与其DO对应的DTO类,此外考虑到购车更多的是承担前台层的功能,BA层不会引入购车,而将其放到了PA层。
    在这里插入图片描述
    PA层的业务对象类图,除了dto 类型外,还增加了消息事件对象,用来将交易的业务变化通过事件消息通知给对其感兴趣的订阅方,要说明的一点是BA层的DO对象,PA层是完全可以使用的。

    核心服务设计:

    服务接入层更多的是前后端交互restful service的设计,交易的PA层实质上已经做了对外开放的微服务设计(使用dubbo框架),服务接入层的restful service几乎是对微服务进行包装参数转换的处理,就没有必要单独说明restful

    service,直接看PA 最重要的几个服务。
    在这里插入图片描述
    核心链路时序设计:

    通过最常规的下单购买和支付流程来说明交易的核心调用链路是怎么样的过程,为了简化说明下面的时序图简化了异常链路的处理过程和人为减少了依赖的业务系统。进行核心链路依赖的设计,是为了在设计阶段更好的去评估依赖的合理性,确保交易的性能,安全性和容灾处理方面的要求。有了核心调用链路图,你才能在设计阶段确定哪些调用是可以减少的,哪些地方可以异步处理,哪些地方可以使用前置缓存,哪些地方需要异步重试,哪些地方不能超时,哪些地方要确保最终一致性,哪些要做幂等处理等等,此外也对下游系统更好的评估自己的流量和响应时间提供了参考依据。

    在这里插入图片描述
    交易这块的技术设计点非常多,分布式高并发系统遇到的经典技术问题,几乎都在着有出现,限于篇幅,将通过接下来的一篇专题文章专门介绍。
    原文路径:原文路径

    展开全文
  • 正是基于这些经历,汪源才提出以能力组、技术平台和方法论为主的标准能力组织、包含专向组的胖中台组织中台组织到平台组织的转化等方法,以应对不同的情况。 台和各前台业务团队是支撑和合作的关系,这两类...
  • DDD到底是什么概念,和微服务和中台之间又有什么样的联系,带你走进DDD!!
  • 如果中台确实是解决企业现有问题的合理方案,那么建设过程伴随的组织架构问题就是企业需要关心的,比如中台团队的人从哪来?经费从哪来?建设中台之后,业务团队的决策权力是不是被大幅缩减?本文采访了多位中台...
  • 大数据中台

    千次阅读 多人点赞 2020-08-28 11:17:11
    数据中台的由来 数据中台最早是阿里提出的,但真正火起来是2018 年,我们能感受到行业文章谈论数据中台的越来越多。大量的互联网、非互联网公司都开始建设数据中台。为什么很多公司开始建设数据中台?尽管数据中台...
  • 数据中台数据体系是在全域原始数据的基础上,进行标准定义及分层建 模,数据体系建设最终呈现的结果是一套完整、规范、准确的数据体 系,可以方便支撑数据应用。 中台数据体系应具备以下特征:·覆盖全域数据:数据...
  • 技术中台建设方法和关键设计

    千次阅读 2020-10-29 08:31:47
    转载本文需注明出处:微信公众号EAWorld,违者必究。作为企业数字化中台建设支撑的技术中台,其前台是企业应用,后台是企业基础设施(网络、存储、计算等资源),可为企业数字化中台建设提供标...
  • 要理解中台,得先将时间拉回到二十年前。那时的CRM不叫CRM,叫九七。大家办业务还只有去营业厅这一条途径。营业员大妈高傲地在九七系统里录入用户信息、业务办理信息。倒是够用。 后来随着业务和客户的增多,原来几...
  • 0、前言 当前,大部分企业不再建设从源数据采集到分析应用的烟囱式系统,更倾向于数据集中采集、存储,并应用分层建设。这种方式一方面有利于应用系统的快速部署,另一方面也...其他组织或企业建设数据中台不一定需
  • 全渠道零售中台与数字化转型(1)-中台的前世今身

    千次阅读 多人点赞 2019-06-25 15:37:59
    本系列博客的目标是计划使用近半年时间创造: ... 全渠道零售中台与数字化转型(2)-中台给企业业务带来什么实际的价值 全渠道零售中台与数字化转型(3)-中台给企业技术带来什么实际的价值? 全渠...
  • 《软件工程》第6章体系结构设计

    千次阅读 2020-06-02 09:33:24
    体系结构设计关注理解一个软件系统应当如何组织,以及设计该系统的整体结构。体系结构设计是设计和需求工程之间的关键性衔接环节,因为它会确定组成一个系统的主要结构构件以及它们之间的关系。体系结构设计过程的...
  • 3、 数据中台组织架构 四、开源数据台架构 1、数据台架构应该具备的能⼒ 2、老师(资深架构师Felix)设计的数据台架构 五、数据台战略思考 1、数据体系及架构的演进 2、 数据台未来发展⽅向 2.1、实时数据...
  • 2. 业务中台采用领域驱动设计(DDD),在其上构建业务能力SAAS,持续不断进行迭代演进。 3. 平台化定位,进行了业务隔离设计,方便一套系统支撑不同玩法的业务类型和便于定制化扩展。 4. 前后端分离,通过服务接入层...
  • 数据中台也是一个数据统一的平台,它不会取代原来的系统,而是把原来组织中分散在各系统的数据实时地汇聚到统一平台之。 其次,数据资产体系建立。 与数仓及其它大数据平台不同的是,汇聚统一之后,做数据资产...
  • 01 阿里中台架构的定义 ...“中台架构,是将企业的核心能力随着业务不断发展以数字化形式沉淀到平台,形成以服务为中心,由业务台和数据中台构建起数据闭环运转的运营体系,供企业更高效的进行业...
  • java实现组织架构

    千次阅读 2021-12-08 17:11:27
    JAVA实现简单的组织架构 主代码块: @Override public Map<String, Object> findTAreaMenu(QueryRequest request, TArea tArea) { Map<String, Object> result = new HashMap<>(4); try { ...
  • 大白话中台系统

    千次阅读 2019-11-11 10:44:47
    什么是中台系统?它是如何诞生的?它长什么模样?我们为什么需要它?一串串的问题不禁浮现在我们的脑海,今天我们就带着这些问题,一起走进中台。  1、中台诞生  任何一个软件系统都是通过帮助客户解决问题来...
  • 中台打破了应用系统的壁垒,从企业全局梳理和规划业务程,重构了组织架构、业务架构与IT 架构。 在梳理了企业的IT 现状并回顾了SOA 的历史之后,我们需要对中台架构进行一番详细的介绍,阿里巴巴的Aliware 团队曾经...
  • 数据中台(四) 组织规划

    千次阅读 2020-09-21 21:25:32
    组织规划步骤 数据中台是企业级战略,支撑企业数字化转型,涉及企业的方方面面,数据中台的战略的执行必然需要企业组织的保障...二、完善组织结构 数据中台的组织架构主要由数据资产管理委员会、数据资产管理中心和各
  • PDM系统的结构设计

    千次阅读 2018-11-04 11:46:51
    1 PDM系统需求分析   PDM是依托IT技术实现企业最优化...它必须是一种可以实现的技术,必须是一种可以在不同行业、不同企业实现的技术,必须是一种与企业文化相结合的技术。因此,它与企业自身密切相 关。 ...
  • 1、解读中台 -- 什么是中台

    千次阅读 2019-10-06 18:57:15
    解读中台 中台,通过对业务、数据和技术的抽象,对服务能力进行复用,构建了企业级的服务能力,消除了企业内部各业务部门、各分子公司间的壁垒,适应了企业,特别是大型企业集团业务多元化的发展战略。基于中台,可快速...
  • 文章目录架构设计请列举出在JDK几个常用的设计模式?什么是设计模式?你是否在你的代码里面使用过任何设计模式?静态代理、JDK动态代理以及CGLIB动态代理静态代理动态代理cglib代理单例模式工厂模式观察者模式装饰...
  • 业务中台采用领域驱动设计(DDD),在其上构建业务能力SAAS,持续不断进行迭代演进。 平台化定位,进行了业务隔离设计,方便一套系统支撑不同玩法的业务类型和便于定制化扩展。 前后端分离,通过服务接入层进行...
  • 数据中台(七) 数据中台架构

    千次阅读 多人点赞 2020-09-23 12:59:15
    数据汇聚是把数据资源通过实时、批量的方式存储到数据中台。基本是按照数据的原始状态堆砌在一起的,是企业对过往所有IT信息化建设积累的成果的融合。 数据开发 数据开发是数据资产内容建设的主战场,是数据价值...
  • 个人思考:中台建设-用户中台-V2

    千次阅读 2020-02-11 15:47:59
    我是从用户中台的业务点出发,结合统一身份认证管理系统(4A或者IAM)来设计用户中台。我得益于《平台级SAAS架构的基础:统一身份管理系统》这篇文章,在这个文章的基础上结合公司现有和将有的业务进行了修订。 ...
  • | 前提1:技术组织结构垂直化 | 前提2:业务线又多又复杂 有了技术中台,是不是就能上天? 总结 就在刚过去的半年里,「中台」成了技术圈内讨论的热门词汇,就连一些名不见经传的小公司,也都纷纷喊出了「要...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 164,163
精华内容 65,665
关键字:

中台组织结构设计