2.1.回归SOA的本质-服务重用 SOA理念的核心价值:松耦合的服务带来业务的复用,通过服务的编排助力业务的快速响应和创新. 现有模式多是烟囱式结合 ESB 企业总线打通不同系统间的交互. 2.2.服务需要不断的业务滋养 烟囱式系统方式以及SOA项目制的建设方式会导致现有系统弊端. 服务所需的滋养是来自新的业务的不断进行服务的接入. 2.3.共享服务体系是培育业务创新的土壤 业务校验保障平台:使用业务规则的方式,通过保障平台对交易进行业务和逻辑上的校验. 2.4.赋予业务快速创新和试错的能力…

一般来说服务能力包括两个层次,一个是底层paas的能力,PaaS层结局大型架构在分布式.可靠性.可用性.容错.监控以及运维层面上的通用需求:第二个层次是业务能力,业务能力提供云化的核心业务支撑能力,这层能力建设的好坏,直接决定了能否真正支持上层业务达到敏捷.稳定.高效. 1.1.淘宝的共享中心概貌 用户中心 商品中心 商品描述能力:商品的描述数据模型:类目属性体系.spu.sku等:商品存储模型:商品数据在数据库中的存储结构:对外提供的服务接口:上层业务通过接口操作商品数据. 商品发布能力:op…

3.1.淘宝平台“服务化”历程 大约2007年,淘宝500人团队,维护一个war包,200多个功能模块. 1)项目团队协同成本高,业务响应越来越慢 2)应用复杂度超出人的认知负载. 3)错误难于隔离[同一个环境,一个jvm] 4)数据库连接能力很难扩展:每一个机器只有10个,但是应用机器过于多,也达到了5000多连接 5)应用扩展成本高 2007年10月,开始进行基于SOA理念新一代服务化框架研发以及采用业务模块逐步迁移的方式进行应用架构的改造.在未来的14个月中将单一应用模式改造成基于SOA理…

1.1.阿里中台发展 组件中台可能问题:组织间业务协作.业务核心能力的沉淀.组织KPI考核等 1.2.企业信息中心发展的症结 1.烟囱式系统建设模式 独立构建独立维护 缺点:1.重复功能建设和维护带来的重复投资:2.打通“烟囱式”系统间交互的集成和协作成本高昂-一般采用构建企业总线[soa],基于服务的方式实现了烟囱间交互的问题:3.不利于业务的沉淀和持续发展-有些业务上线后因依赖过多,后续几年中从没更新服务或提升: 结论:前两个是成本和效率的角度,第三个是发展的角度:这样的系统一般上线5-8年…

此文是我阅读<企业IT架构转型之道>一书的学习笔记,所有内容出自钟华老师的这本书. 零.为何读<企业IT架构转型之道> 在加入X公司后,开始了微服务架构的实践,也开始了共享平台服务的建设,在这方面阿里巴巴的中台战略是一个较好的参考.于是,领导就赠了这么一本<企业IT架构转型之道>给我,希望我学以致用,更多的是有这样的一个眼界去指导我们的中台架构设计.因此,我花了两周时间快速地阅读了一下此书,总结了此文作为学习笔记以供日后复习用.此书的确讲了一些干货,虽然很多内容留于表面…

1 出发点:企业IT系统建设普遍面临的问题和处境 很多企业面临的问题和处境: 『烟囱式』系统建设模式. 当业务部门提出业务需求,信息中心部门进行系统集成商的招投标,再进入到需求收集.需求分析.开发.测试.上线的项目周期中.某种程度上,每个新系统的上线都预示着一座新的烟囱矗立而成.这种完全基于业务需求建设系统的方式,已经成为过去20多年企业建设IT系统的标准流程,导致IT系统建设早的企业内部系统烟囱林立.这正是今天很多企业面临互联网转型难的根结所在. 它带来三大弊端: 重复功能建设和维护带来的重复…

放假三天,用部分时间阅读了企业IT架构转型之道这本书.第一遍潦草读完,就感觉收益颇多.这本书值得多读几遍,适合精度. 作为银行IT开发人员,在央企IT成本部门的大背景下,开发过程中遇到的诸多疑惑.困惑逐渐累积在心头,如同路口电线杆上的线缆,日益纠缠,难以厘清.但这些困惑从来没有在脑海里面消失,一旦遇到闲暇的时间就会冒出来. 读完转型之道这本书,不禁感叹阿里巴巴的强大.阿里在高速发展的10年里面,围绕解决其核心业务,在技术上积累的解决方案.方法论令人惊叹. 银行,尤其是中国的几家大银行,如今面临的…

  一.什么是业务中台 概念来自于阿里,介于前台和后台(此后台指的是云计算.数据库.消息队列.缓存等基础服务) 采用共享式架构设计解决以往烟囱式架构设计的资源浪费.重复造轮.试错成本高的问题 阿里的中台架构: 二.业务中台的好处 传统烟囱式架构的缺点: 项目制下的产物,相似功能重复建设,比如各业务中通用的用户.订单.会员.评价等功能,开发和维护成本高 数据分散,格式不统一,无法进行某个领域的业务建模 团队成员按照项目组织,经常项目做完即走,无法深入了解业务,无法培养领域专家 创新业务试错成本过高…

Spring实战第二章学习笔记----装配Bean 创建应用对象之间协作关系的行为通常称为装配(wiring).这也是依赖注入(DI)的本质. Spring配置的可选方案 当描述bean如何被装配时,Spring具有非常大的灵活性,它提供了三种主要的装配机制: 在XML中进行显示装配. 在Java中进行显示装配. 隐式的bean发现机制和自动装配. 在这本书中作者建议尽可能使用自动配置的机制.显示配置越少越好.而当你必须要显示配置bean时(比如有些代码不是你维护的,而你需要为这些代码装配bea…

本书的第二个部分总结了有关编程实践相关的内容,每一个章节都非常不错,捡取了其中5个章节的内容.对大家组织高维护性的代码具有辅导作用. 5个章节如下—— 一.UI层的松耦合 二.避免使用全局变量 三.事件处理 四.将配置数据从代码中分离出来 五.抛出自定义错误 一.UI层的松耦合 如果两个组件耦合太紧,则说明一个组件和另一个组件直接相关,这样的话,如果修改一个组件的逻辑,那么另外一个组件的逻辑也需要修改.比如,有一个名为error的CSS类名,它是贯穿整个站点的,它被嵌入到HTML之中.如果有一天…