前段时间,我的一个小伙伴跳槽到了某大型国有企业,刚到公司不久,老板给交给他一个重要项目——公司的数据规划。老板交代:“要搞一个数据台架构,涵盖数据资产管理、数据治理、数据分析等,同时这个数据,要体现去中心化,甚至无中心化的理念”。我这哥们儿有过多年的数仓架构经验,并参考了业界主流的数据台架构,很快就“照猫画虎”的搞了一个数据台架构图出来。当他拿走自己的“得意之作”,找老板汇报的时候,
传统企业平台都是烟囱式的系统架构,企业内部为了迎合业务发展不停的打造各种系统,导致各系统间的重复功能建设和维护带来的重复投资。重复投资不仅消耗的是人力,财力还有时间。但打通烟囱式系统间交互的集成和协作成本高昂,各大企业不得不借助ESB产品,构建企业服务总线,打通各系统间的交互问题。但这种借助ESB“中心化”的服务架构缺点也有不少,“中心化”架构的所有服务调用者和服务提供者之间的交互都必须通过这个中
  到处都在喊,到处都是这个词在我看来已经被滥用了。在有些人眼里:就是技术平台,像微服务开发框架、Devops平台、PaaS平台,容器云之类的,人们都叫它“技术”。在有些人眼里:就是微服务业务平台,像最常见的什么用户中心,订单中心,各种微服务集散地,人们都叫它“业务”。在有些人眼里:应该是组织的事情,在释放潜能:平台型组织的进化路线图 (豆瓣)中就
何为数据服务?通俗来讲就是数据在落地实施过程的一个对外输出数据的环节,将数据服务化后提供给业务系统,将数据生产为一个个数据API,以更高效的方式提供给业务。传统业务开发的痛点数据主要存在于关系型数据库、数据仓库,而在传统业务开发使用数据的过程中会遇到如下痛点: 一、查询数据成本高1、部分数据查询需要在调用接口时去计算复杂的业务关系; 二、烟囱式开发成本高1、增加一个报表
首先我们看下阿里巴巴Aliware团队对企业的定义。即企业是由业务数据构建起数据闭环的运营体系,实现以数字化资产的形态构建企业核心差异化竞争力。在原来我谈企业的时候,很少专门谈到数据和业务,更多谈的是技术和业务,技术类似我们原来说的技术平台层和业务不相关。而对于业务,其中包括了以数据能力提供为主的微服务模块组件,也包括了业务规则处理为主的组件,还包括了
与DDD概念什么是按照可复用原则,将通用的、可复用的能力沉淀到,完成企业级业务模型重构落地的技术实现有很多种,当前微服务架构是公认的最佳实践。台本质是业务领域的子域微服务与DDD是共生关系微服务提倡将应用进行服务化拆分,通过业务领域边界实现服务边界的划分。而微服务的拆分困境在于不知道业务或者应用的边界在什么地方DDD恰好提供一种基于业务界限上下文边界来划分业务的方法DDD是一种设
关于中心化和去中心化的问题,已经是老生常谈了。中心化的优缺点都很明确,优点就是容易部署、容易维护,在服务压力较稳定的情况下,是成本最低的解决方案。缺点也是很显然,功能复杂之后管理困难,冲突频繁,性能不易线性扩展,容易单点故障。去中心化或者说分布式就是为了解决这个问题而出现的。搭建企业级的,意味着所有前台的请求都会送到你这里,压力大小可想而知,并且因为小前端带来的创新产品很可能会带来爆款产品,所
10 微服务落地的技术实践如今,做一个优秀的程序员越来越难。激烈的市场竞争、互联网快速的迭代、软件系统规模化发展,无疑都大大增加了软件设计的难度。因此,对于架构师的能力要求也越来越高,就像我的一本书里写道的:作为顶级架构师应当具备这样两个核心能力: (1)能够将业务转换为技术; (2)能合理利用技术支撑业务。“不想当将军的士兵不是好士兵”,因此作为普通开发人员的你,也应当树立成为顶级架构师的目标,
今天将从以下这三方面,来分享一些海量高并发的经验: 模式和微服务架构到底有什么样的关系海量并发的业务台架构如何设计与实践秒级新业务接入的交易如何设计和实践 一、模式与微服务架构的关系 现在大家应该都知道,最早是由芬兰一家著名的游戏公司Supercell提出的,以小前台的模式来组织若干个开发团队。 也就是说,你的每个前台的开发团队,只需要了解
文章目录一、数据服务简介二、开源方案介绍1 Rocket-API2 Magic-API3 Dataway4 APIjson5 Graphql三、详细对比四、推荐度 一、数据服务简介笔者认为数据应该具备以下能力:获取数据处理数据分享数据展示数据数据服务对应的是分享数据的能力。数据服务的能力体现为,通过配置的而不是编码的方式将已有数据发布成接口,供数据需求者调用。为什么要用数据服务? 为了减少开
(2020.12.21)-数据服务体系建设一、数据服务体系概念1、定义与定位数据服务体系就是把数据变为一种服务能力,通过数据服务数据参与到业务之中,激活整个数据,也是数据的价值所在;数据服务是对数据进行计算逻辑的封装(过滤查询、多维分析和算法推理等计算逻辑),生成API服务,生成数据应用可以对接数据服务API,让数据快速应用到业务场景。2、主要分类基础数据服务:面向的对象是物理表数据
《DDD实战》读书笔记五(介绍及DDD、微服务三者的关系)台中概念阿里的定义定义理解要做什么业务数据台前后台的协同前台中业务数据DDD、微服务的关系DDD本质台本质DDD、微服务的协作模式协作模式建模 台中概念阿里的定义是一个基础的理念和框架,我们要把所有的基础服务的思路建设,进行联通,共同支持上端的业务。业务更多的是支持在
不就是微服务吗?这种说法实际上混淆了微服务的定义,要说清楚这个问题,就要先了解,什么是?什么是微服务微服务之间有什么样的关系?什么是 来自阿里官方的定义: 企业就是,将企业的核心能力随着业务不断发展以数字化形式沉淀到平台,形成以服务为中心,由 业务数据构建起数据闭环运转的运营体系,供企业更高效的进行业务探索和创新,实现以数字化资产的形态构建企业
作者:人月神话简介:多年SOA规划建设,私有云PaaS平台架构设计经验,长期从事一线项目实践今天这篇文章作为对SOA,微服务等大量基础概念的一次统一说明。我始终认为,当你在学习一个新的知识和技术点的时候,一定不要马上陷入细节,而是需要用你自己最容易理解的方式形成对该事物的核心概念模型理解。包括我们现在说的很多的微服务。如果你原来就接触过SOA,接触过组件化开发思想,那么你理解
一、客户在微服务化实践过程遇到的问题(源自真实案例)某跨国领军企业,以自上而下全新分析、设计为思路,以识别的业务对象为业务边界识别微服务,以重新开发、数据迁移做为手段实践微服务,发现依然无法达到1-2weeks持续交付的目标,不同领域部门质疑其方法的合理性。某金融业客户,以SOA方法划分微服务粒度,以微服务框架做为实现手段,坚持保持传统需求管理、瀑布方法,结果出现开发版本依赖、构建依赖、上线依赖
台中这一概念,最近在国内大热。阿里、腾讯、百度、京东、美团、滴滴等一众互联网巨头,从去年到今年,接连开始组织架构的调整,意图建设。也有很多人认为,并不是解决一切问题的法宝,小公司不需要用,只有发展到一定规模的公司才需要。是不是要有适合什么阶段/规模的公司?是一个可以值得去讨论的问题。1.什么是,到底要解决什么问题?这个最早由阿里在2015年提出的“大中,小前台”
在前面的文章,我们介绍了“数据服务”对于“数据”的重要性,并讲解了数据服务解决的问题及其核心功能,在这个系列的最终篇我们展开聊聊数据服务的四大关键技术,然后总结一下数据服务架构的三大关键点,希望对大家有所帮助。为了使数据具备快速响应前端业务需求的能力,主流的数据均采用了云原生技术来构建数据服务层,实现数据服务的快速开发、有序落地。云原生是一种构建和运行应用程序的方法,是一套技术体系和
从去年初开始接触微服务架构的一些理念,然后到今年开始实施系统第四个大版本的架构升级决定采用这套架构理念。  最近关于微服务架构的讨论还是多起来,因为国外一些著名互联网公司(如:Amazon、Netflix 等)从实践摸索出了一套新的大型系统架构方法论,并取得了成功,树立了很好的示范,然后这套方法论渐渐就被一些技术理论派  人士命名为微服务架构(Microservices)。
常常有人这样问:不就是微服务吗?都是以服务化的方式对外提供能力,老瓶装新酒嘛,炒作概念而已。其实并不是微服务,那么微服务到底有什么关系呢? 什么是台中是业务抽象层面的复用平台,其核心是将具有共性的业务抽象出来,并提供复用。复用定义了的核心价值,具备可复用性才能达成降本提效的目的,为企业带来效益。的搭建也不仅仅是个技术问题,还应该跳出单一的业务线,从企业架构的层面
常见的疑惑与问题(1)业务微服务的区别?   二者解决的是不同的问题,也处于不同的抽象层次。   解决的是业务领域复用的问题,微服务解决的是技术领域的"组件编译时依赖"造成的问题。   业务不一定是微服务架构的,微服务架构也不一定是为了能力复用的问题  (2)技术与中间件的区别?   技术强调从全局业务视角的出发,中间件则主要从技术去重的视角出发。  (3)就只有业务
  • 1
  • 2
  • 3
  • 4
  • 5