淘宝技术架构分享
淘宝技术架构分享
，HSF 使用的时候需要单独的下载一个hsf.sar 文件放置到jboss 的
；弊端也很明显：增加了环境的复杂度，需要往jboss 下扔sar
设计的主要原因。HSF 工作原理如下图：
HSF SAR 文件到Jboss 的Deploy 目录。
大型分布式的基础支撑。使开发人员无需过多的关注应用是集中式的，还是分布式的，可以更加专注于应用的业务需求的实现，这些纯技术
的需求都由HSF 来解决。
（2）HSF 的系统架构
I. HSF 交互场景图
客户端（消费端）从配置中心获取服务端地址列表—>和服务端建立连接开始远程调用—>服务端更新通过notify（类似B2B 的naplio）
系统通知客户端。服务端和客户端都有对应的监控中心，实时监控服务状态。客户端，配置中心，服务端，notify，之间的通信都是通过TB Remotion
API 去搞定的。
II. TB Remoting 架构图
底层基于分布式框架Mina，主要的代码都是通过
B2B 的Dubbo 也是基于这个NIO 框架的。Mina
商品，付款，确认，退款，评价，社区互动等。
产品：淘宝对产品定义和B2B 有差别，淘宝的业务拆分较细，服务化做的较成熟，所以前台应用对应的业务非常纯粹，如Detail 系统可
能就一个detail 页面，无数据库连接，所有数据来自底层的各种服务化中心，功能专一逻辑清晰纯粹，不过也正因为这样，淘宝的一个产品
淘宝前端应用
HSF接口
UIC IC SC TC
PC
Forest 推送给“淘宝前端应用”
淘宝共享服务
淘宝技术架构简介
• 价值
– 用同步的语义来实现异步的调用
ngx_lua原理
• 每个Nginx工作进程使用一个Lua VM，工 作进程内所有协程共享VM • 每个外部请求都由一个Lua协程处理，协程 之间数据隔离 • Lua代码调用I/O操作接口时，若该操作无 法立刻完成，则打断相关协程的运行并保 护上下文数据 • I/O操作完成时还原相关协程上下文数据并 继续运行
系统过载保护
• 判断依据
– 系统的loadavg – 内存使用（swap的比率）
• sysgurad模块
sysguard on; sysguard_load load=4 action=/high_load.html; sysguard_mem swapratio=10% action=/mem_high.html
– 防hashdos攻击 – 防SQL注入 – 防XSS
• 标准Nginx无输入体过滤器机制的问题 • 例子（防hashdos攻击）
– 如果所有POST内容都在内存中，占用内存过大 – 否则性能不高，内容可能被buffer到磁盘 – /2012/01/amechanism-to-help-write-web-applicationfirewalls-for-nginx/
ngx_lua原理
代码示例
location /http_client { proxy_pass $arg_url; } location /web_iconv { content_by_lua ' local from, to, url = ngx.var.arg_f, ngx.var.arg_t, ngx.var.arg_u local iconv = require "iconv" local cd = iconv.new(to or "utf8", from or "gbk") local res = ngx.location.capture("/http_client?url=" .. url) if res.status == 200 then local ostr, err = cd:iconv(res.body) ngx.print(ostr) else ngx.say("error occured: rc=" .. res.status) end '; }
淘宝电子商务部组织架构方案
电子商务部方案1、组织架构人员组成经理，美工，摄影，企划，客服；备注：其中产品部的岗位职责暂归客服部执行；2工作分工发货：晚班人员实施；售后：小郭专门负责；产品：包括库存管理、测量尺码及汇总由小郭负责，小季协助；客服及分销：小郭与小明分工协助；摄影：外包负责、小季协助；设计：店铺装修、宝贝设计、宝贝上架及文案小季负责；企划：谢云杰负责、小季协助；3、工作职责经理：1）、战略布局与实施1. 双熊班纳品牌定位、经营理念；2. 行业地位及市场细分策略3. 淘宝分销和网上渠道战略4. 制定短期、中长期目标与规划5. 完成战略与销售目标2）、部门管理1. 绩效考核，有奖有罚3. 定制工作标准与流程4. 部门内外沟通与协助5. 调节团队氛围，增强战斗力客服：通过在线聊天工具，负责在淘宝上和顾客沟通，解答顾客对产品和购买服务的疑问；产品数据在线维护管理和宝贝的下架，登录销售系统内部处理订单的完成，制定快递单，整理货品等；客户关系维护工作，在线沟通解答顾客资询，引导用户在商城上顺利的购买，促成交易；美工：负责淘宝商城的店铺装修和整体形象设计；负责货品的详细设计及宝贝上传；策划和设计活动专题及广告条设计摄影：负责公司货品的拍摄；企划：根据公司发展战略，制定淘宝店铺的营销策划方案。
要有会使用淘宝7大营销工具(直通车/淘客/淘江湖/卖霸/钻石展位/焦点图/店铺街)的经验来提升店铺流量。
定期针对推广效果进行跟踪、评估，并提交推广效果的统计分析报表，及时提出营销改进措施，给出切实可行的改进方案。
负责各项品牌的宣传推广方案的设计、讨论和实施。
淘宝数据魔方数据分析统计，热销产品走势，热门成交关键词的提取。
淘宝网的架构演进
DB DB
Messaging
JBoss MVC Spring iBatis Remoting JBoss MVC Spring iBatis
DAL
运 行 状 况 监 测 和 报 警 系 统
Node1
Node2
Noden
Read/Write …… Node1 Node2 Noden
Tolerance of network Partition
Basically Availble
Soft-state Eventual Consistency
数据库减负
数据库能做的事
–存数据 –单条查询 –多表关联查询 –大量数据实时在线分析 –通过存储过程，函数来处理业务
简化方案
WebX介绍
Apache Turbine
–Servlet-based –MVC Pattern –Velocity/JSP –Turbine Services(Upload/Security) –Pipeline/Valve WebWork Spring
页面驱动开发
约定优于配置
发展阶段
备份 隔离 集群 分割 异步 去小型机去Oracle
拆分阶段
理论依据
–虚拟化 –CAP/BASE 基础设施 –去Oracle –Notify –HSF
CAP/BASE
ACID(atomicity/consistency/isolation/durability) Consistency Availability
Notify介绍
浅谈淘宝类目属性体系：商品搜索背后的逻辑架构
浅谈淘宝类目属性体系：商品搜索背后的逻辑架构[核心提示] 淘宝拥有百万家商户和超过10亿的商品数，它如何让用户精准地找到想要的商品呢？其背后有着强大的技术支撑。
淘宝目前在线商品数超过10 亿，如何精准的帮助用户找到他想要的商品呢？经过多年的探索，淘宝通过建立一套完整的类目属性体系，终于较好的解决了这一问题，今天就跟大家一起来谈谈淘宝的类目属性体系。
一点点历史和架构2003 年淘宝刚上线时，商品量很少，没有分类。
后来，商品量上百，开始有了对商品进行单级分类，有点类似于现在的一级行业类目。
等到商品上万的时候，商品的单级分类已经不能满足需求，开始有了多级分类，就是一颗类目树了。
从06 年开始引入了属性，商家按照属性模板填写属性，用户可以按照属性筛选商品。
到了08 年，开始将前后台类目分开，用户根据前台类目筛选商品，商家将商品挂到后台类目上，前后台类目树之间建立好映射。
今天的淘宝类目属性体系主要由后台类目树、前台类目树、挂载在后来叶子类目上的商品属性模板以及管理前后台类目之间映射关系的类目管理平台组成，整体架构如下：从图中可以看出，淘宝类目属性体系是一个非常基础的数据服务，在商品发布页上商家选择后台类目上传商品信息，详情页上以面包屑的方式给用户显示商品所属的前台类目，在搜索结果页上让用户根据前台类目筛选商品。
运营同学可以通过一个管理后台来管理前后台类目之间的映射关系以及后台类目的属性模板。
后台类目后台类目面向商家，主要用于商品的分类和属性管理。
商家上传商品时见到的就是后台类目，如下图：后台类目有如下特点：后台类目树中最重要的是叶子类目，也就是类目树上不能再往下分的类目,任何商品都必须挂载到后台叶子类目上。
叶子类目挂载属性模版，商家发布商品时选择好类目之后会根据属性模版，补充必填的商品属性信息，方可成功上传商品。
后台类目相对稳定，不能随便删除，叶子类目不能重复。
前台类目前台分类面向用户，方便用户筛选查找商品，大部分时候用户见到的类目都是前台类目。
淘宝技术架构介绍, 了解淘宝,了解淘宝的架构需求
pipeline 页面布局
Screen Layout Control
多模板引擎
Jsp Velocity FreeMarker
V2.0 淘宝项目管理工具 AntX
类似maven 脚本编程语言 AutoConfig 依赖管理，冲突检测
V2.1 的需求
提高性能 增加开发效率 降低成本
V2.1 2004.10 – 2007.01
TBStore
Read/Write
Oracle Oracle Oracle Oracle
dump
Search
Read/Write
Node Node
1
2 ……
Node n
V2.1逻辑结构
表示层
Service
业务请求转发
Framework
S
UC
UC 业务流程处理 UC
UC
P
R
AO
AO
AO
AO
I
业务逻辑层
Node 1
Node 2
Node n
V2.1 TaobaoCDN
squid apache+php lighttpd 静态页面（包括php页面）、图片、描述 最初只有杭州和上海两个站点 现在发展到北京、广州、西安、天津、武
汉、济南等近10个站点 现在每天高峰期30G流量/秒
V2.1 session框架
Put/Get Data
Node 1
Node 2
Node n
V2.2 搜索引擎
垂直/水平 分割
AAPPPP
AAPPPP
Merge
Node1
Node2 ……
Node n
Col1
Node 1
技术选型tb的描述 -回复
技术选型tb的描述-回复技术选型是指在项目或产品开发过程中，根据特定的需求、目标和条件，选择最适合的技术框架或工具。
本文将围绕着“技术选型tb的描述”这个主题展开讨论，重点侧重于tb（淘宝）这一电商平台的技术选型及相关方面的介绍。
一、淘宝的背景与介绍淘宝是中国最大的综合性电子商务平台，于2003年由阿里巴巴集团创立。
淘宝以C2C模式为基础，打造了一个拥有数亿用户的购物平台。
随着互联网的快速发展和消费行为的改变，淘宝不断优化和升级自身的技术架构，以应对日益增长和复杂化的业务需求。
二、技术选型的重要性技术选型在电商平台的开发和运营中扮演着重要的角色。
通过合理的技术选型，可以提高系统的性能和稳定性，降低系统的开发和运维成本，优化用户体验以及提升系统的可扩展性。
三、淘宝的技术架构1. 分布式架构：淘宝采用了分布式架构来应对高并发的访问量和海量的数据处理需求。
通过将业务按照不同的功能分解成独立的模块，并采用分布式计算和存储的方式，使得系统能够快速扩展和横向伸缩。
2. 高可用性和容错性：淘宝通过引入容灾机制和高可用性设计来保证系统的稳定运行。
例如，采用分布式缓存和负载均衡等技术，以及多活数据中心部署和数据冗余备份策略等，确保了系统在单点故障或数据中心级别故障时的高可用性和容错性。
3. 数据挖掘和智能推荐：淘宝依托阿里巴巴集团强大的技术能力，构建了一套完整的数据挖掘和智能推荐系统。
通过大数据分析和机器学习算法，淘宝能够根据用户的历史行为和偏好，提供个性化的商品推荐和搜索结果排序。
4. 移动化支持：随着移动互联网的普及，淘宝将移动化作为重点发展方向。
淘宝借助大数据和云计算等技术手段，构建了移动端的技术架构，包括手机客户端和移动Web应用等，以提供便捷的购物体验和丰富的移动服务。
四、技术选型的考虑因素在进行技术选型时，淘宝考虑了以下几个重要因素：1. 可扩展性：淘宝需要能够应对数亿用户的同时访问需求，因此选用的技术框架必须具备良好的可扩展性，能够支持大规模并发和海量数据处理。
淘宝功能架构图ppt课件
SPU搜索
…搜索
1
介绍上图中提到的各个系统缩写意思
1.UIC: 用户中心(User Interface Center),提供所有用户信息相关的读写服务，如基本信息，扩展信息，社区信息，买卖家信用等级等等。 淘宝现在有两类卖家B 和C，这是通过在用户身上打不同的标签实现的，我们这次的无名良品卖家也是通过在用户身上打特殊的标签来区别于淘宝 已有的B 和C 类卖家。淘宝的TOP 平台已经开放了大部分的UIC 接口。 2.IC：商品中心(Item Center),提供所有商品信息的读写服务，比如新发商品，修改商品，删除商品，前后台读取商品相关信息等等，IC 是 淘宝比较核心的服务模块，有专门的产品线负责这块内容，IC 相关接口在TOP 中占的比重也比较大。 3.SC：店铺中心(Shop Center),类似中文站的旺铺，不过淘宝的SC 不提供页面级应用，提供的都是些远程的服务化的接口,提供店铺相关信 息的读写操作。 如：开通店铺，店铺首页，及detail 页面店铺相关信息获取，如店内类目，主营，店铺名称，店铺级别：如普通，旺铺，拓展版， 旗舰版等等。装修相关的业务是SC 中占比重较大的一块，现在慢慢的独立为一个新的服务化中心DC(design center),很多的前台应用已经通过直 接使用DC 提供的服务化接口直接去装修相关的信息。 4.TC：交易中心(Trade Center),提供从创建交易到确认收货的正 向交易流程服务，也提供从申请退款到退款完成的反向交易流程服务. 5.PC：促销中心(Promotion Center),提供促销产品的订购，续费，查询，使用相关的服务化接口，如：订购和使用旺铺，满就送，限时秒 杀，相册，店铺统计工具等等。 6.Forest：淘宝类目体系：提供淘宝前后台类目的读写操作，以及前后台类目的关联操作。 7.Tair：淘宝的分布式缓存方案，和中文站的Memcached 很像。其实也是对memcached 的二次封装加入了淘宝的一些个性化需求。 8.TFS：淘宝分布式文件存储方案(TB File System)，专门用户处理静态资源存储的方案，淘宝所有的静态资源，如图片，HTML 页面，文本 文件，页面大段的文本内容如：产品描述，都是通过TFS 存储的。 9.TDBM：淘宝DB 管理中心(TB DB Manager), 淘宝数据库管理中心，提供统一的数据读写操作。 10.RC：评价中心(Rate center),提供评价相关信息的读写服务，如评价详情，DSR 评分等信息的写度服务。 11.HSF：淘宝的远程服务调用框架和平台的Dubbo 功能类似，不过部署方式上有较大差异，所有的服务接口都通过对应的注册中心（config center）获取。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
UIC[用户中心]
IC[商品中心]
TC[交易中心]
PC[促销中心]
DC[装修中心]
RC[评价中心]
SC[店铺中心]
Forest[类目体系]
核心业务服务：提供各种核心业务模块的服务化接口，接口按使用方式分两类：
（1）通过HSF方式调用的远程服务化接口 （2）通过定期推送服务端数据文件到客户端的CS调用 图中：蓝色标注的系统的部分接口使用第二中方式调用，其他系统基本都是基于HSF方式的远程调用。
购和使用，广告系统，社区发帖，淘宝客等等，前台浏览相对使用较少。
(2)买家行为:集中在前台：店铺浏览，宝贝的浏览，社区浏览等比重较大，买家后台功能主要定位在后台的“我是买家”Tab 页下，包括拍
商品，付款，确认，退款，评价，社区互动等。
产品：淘宝对产品定义和 B2B 有差别，淘宝的业务拆分较细，服务化做的较成熟，所以前台应用对应的业务非常纯粹，如 Detail 系统可
Tair[分布式cache] TDBM[数据库管理] Config[注册中心] TFS[分布式存储] HSF[远程调用框架]
基础服务: 提供最基础的共享服务，这些服务中心提供的功能基本与业务无关。
基本上这些服务在B2B都有，只是名字不一样而已，大体的功能也类似，不过实现方 式有差异，会在下面具体做介绍。
Oracle
淘宝共享服务
UIC
IC
SC
TC
PC
Search接口 LB配置
数据共享系统 TDBM
Tair
TFS 快照
Search 接口
Dump中心
Build索引
分发索引文件
搜索引擎系统 大C搜索
SPU搜索
实时搜索 …搜索
我介绍下图中提到的各个系统缩写是神马意思：
1.UIC: 用户中心(User Interface Center),提供所有用户信息相关的读写服务，如基本信息，扩展信息，社区信息，买卖家信用等级等等。 淘宝现在有两类卖家 B 和 C，这是通过在用户身上打不同的标签实现的，我们这次的无名良品卖家也是通过在用户身上打特殊的标签来区别于淘宝 已有的 B 和 C 类卖家。淘宝的 TOP 平台已经开放了大部分的 UIC 接口。
HSFSpringProviderBean: 会进行初始化，将向config server 注册当前这个bean 服务。这一注册过程，简单理解其实就是告诉config
server：IP 为xxx.xxx.xxx.xxx 的机器提供了xxx 服务。这样，config server 就可以根据服务调用者的请求中的服务名来转发推送服务地址了。
(1) HSF 是神马？
[High-Speed Service Framework] 淘宝的高速远程调用框架，类似中文站的 Dubbo，基于 Mina 框架开发，它是淘宝应用从集中式走入 大型分布式的基础支撑。使开发人员无需过多的关注应用是集中式的，还是分布式的，可以更加专注于应用的业务需求的实现，这些纯技术 的需求都由 HSF 来解决。
通过上面的几张图可以明显的看出服务化给整个系统架构带来的好处：
(1) 应用间的耦合降低，在服务化接口成熟的情况下，扩展新的业务需求变得方便，主要就是一个组合服务化接口的过程。 (2) 开发人员可以专心关注业务，而不用考虑分布式领域中的各种细节技术，例如远程通讯、性能损耗、调用的透明化、同步/异步调
II．随着业务发展，抽提部分核心业务之后的状态：对前台业务做了切分，抽提了部分核心业务成为独立的服务化提供中心。不过抽提的 业务较少，这个阶段缺少对不同层的针对性优化，比如监控，容灾，事务等等
III．大规模使用 HSF，服务化相对成熟之后的状况：前端应用高度分化，拆分成一个个功能单一的应用系统，后端服务化接口也划分的较 细同时针对不同业务和具体的技术实现做个性化优化，增强了各个节点的健壮性，高效性。
4.TC：交易中心(Trade Center),提供从创建交易到确认收货的正 向交易流程服务，也提供从申请退款到退款完成的反向交易流程服务. 5.PC：促销中心(Promotion Center),提供促销产品的订购，续费，查询，使用相关的服务化接口，如：订购和使用旺铺，满就送，限时秒 杀，相册，店铺统计工具等等。 6.Forest：淘宝类目体系：提供淘宝前后台类目的读写操作，以及前后台类目的关联操作。 7.Tair：淘宝的分布式缓存方案，和中文站的 Memcached 很像。其实也是对 memcached 的二次封装加入了淘宝的一些个性化需求。 8.TFS：淘宝分布式文件存储方案(TB File System)，专门用户处理静态资源存储的方案，淘宝所有的静态资源，如图片，HTML 页面，文本 文件，页面大段的文本内容如：产品描述，都是通过 TFS 存储的。具体设计和优缺点会在下面详细介绍。 9.TDBM：淘宝 DB 管理中心(TB DB Manager), 淘宝数据库管理中心，提供统一的数据读写操作，具体设计在下面详细介绍。 10.RC：评价中心(Rate center),提供评价相关信息的读写服务，如评价详情，DSR 评分等信息的写度服务。 11.HSF：淘宝的远程服务调用框架和平台的 Dubbo 功能类似，不过部署方式上有较大差异，所有的服务接口都通过对应的注册中心（config center）获取。
二.淘宝服务化进程
罗马非一日建成，上面看到的相对成熟的服务化中心也是在淘宝业在务发展过程中不断的遇到问题，解决问题的过程中沉淀下来的，下面给 大家简单图示下淘宝的服务化进程：
I．最初的淘宝应用架构状况：业务高度耦合，不同的功能模块基本都糅合在一个系统中，错综复杂，很有 exodus2 当初的味道啊！
用户：淘宝用户分两类：买家和卖家，不过很多的卖家也会在淘宝买东西，所以他们既是卖家也是买家，因此最好是按照用户行为分：卖
家行为和买家行为。买卖家行为都会涉及的系统包括：店铺，商城，交易，商品，社区等等。涉及到的功能有较大差异：
(1)卖家行为:主要定位在个人后台，且主要定位在后台的“我是卖家”TAB 页下的功能，包括：店铺管理，商品管理，订单管理，服务订
（2）HSF 的系统架构
I. HSF 交互场景图
客户端（消费端）从配置中心获取服务端地址列表—>和服务端建立连接开始远程调用—>服务端更新通过 notify（类似 B2B 的 naplio） 系统通知客户端。服务端和客户端都有对应的监控中心，实时监控服务状态。客户端，配置中心，服务端，notify，之间的通信都是通过 TB Remotion API 去搞定的。
1.1. HSF 部署模型 下图 HSF 部署模型：使用之前，需要拷贝淘宝提供的 HSF SAR 文件到 Jboss 的 Deploy 目录。
SAR 文件 download URL：/hsfversion/ 1.2.HSF 发布和订阅服务和调用
1. JBoss 服务器启动后，启动HSF SAR 应用（即taobao.hsf.sar，本地开发机放在%DEPLOY_DIR%中，线上机器放置在 /home/admin/${appName}/target下） 2. 应用自身启动，Spring 容器初始化。这时：
II. TB Remoting 架构图
底层基于分布式框架 Mina，主要的代码都是通过 NIO 实现的。关于 Mina 的具体实现大家可以 google，篇幅限制不细讲. B2B 的 Dubbo 也是基于这个 NIO 框架的。Mina 上层封装的事件扩展，连接管理，线程池管理，序列化，包括最上面的 Façade 接口都是淘 宝根据自身的需求做了一些封装，如果对这块感兴趣可以看看 HSF 的源码, 需要的可以联系我！
能就一个 detail 页面，无数据库连接，所有数据来自底层的各种服务化中心，功能专一逻辑清晰纯粹，不过也正因为这样，淘宝的一个产品 可能是分布在多个应用系统中，单个应用很难称为一个产品。 淘宝更喜欢用产品线的概念，往往是一个团队负责一条产品线，跨几个功能纯粹的应用, 如：商品线 交易线 店铺线 江湖线 商城线等。
ABTN网络
GTM分流
淘宝接入层 交换机
广告检索系统
LB设备
淘宝用户群
DNS CDN系统
LB设备
站点缓存
静态页面
图片
DW部门数 据处理
打点/埋点 日志
店铺
商城
互动社区
无线
商品
……
淘宝片
HSF接口
TDDL/读写分离 Ibatis接口
数据库系统 Mysql
2.淘宝服务化架构：
客户（卖和买）
店铺
商城
社区
无名良品
商品
交易
无线
….
前台系统：直接和用户打交道，它们依赖于各种核心业务中心提供的服务化接口，淘宝服务
化 做的比较早，相对B2B来说比较成熟，这种高度服务化的方式有三点好处： (1)搭建新应用很敏捷，所需要做的就是：整理业务流à 组装服务化接口à 渲染页面 (2)增强应用健壮性，只要保证服务化接口的稳定性容灾性，前台应用调用基本都不会有大的故障 (3)服务化接口把类似的业务接口抽象的很纯粹，使得性能观察和优化更有针对性，更专注！
淘宝技术架构分享
中文网站技术部-B2C 商城 -- 郎中锋【花名:八神】 Email：ngzf@
一，淘宝技术架构
1. 淘宝整体网络架构：
淘宝客户群
淘宝直通车
淘
宝
广告DB
广
告
系
Dump数据
统
Build索引数据
广告点击消费
DNS
JS调用广告展示
计费系统
2.IC：商品中心(Item Center),提供所有商品信息的读写服务，比如新发商品，修改商品，删除商品，前后台读取商品相关信息等等，IC 是 淘宝比较核心的服务模块，有专门的产品线负责这块内容，IC 相关接口在 TOP 中占的比重也比较大。
3.SC：店铺中心(Shop Center),类似中文站的旺铺，不过淘宝的 SC 不提供页面级应用，提供的都是些远程的服务化的接口,提供店铺相关信 息的读写操作。 如：开通店铺，店铺首页，及 detail 页面店铺相关信息获取，如店内类目，主营，店铺名称，店铺级别：如普通，旺铺，拓展版， 旗舰版等等。装修相关的业务是 SC 中占比重较大的一块，现在慢慢的独立为一个新的服务化中心 DC(design center),很多的前台应用已经通过直 接使用 DC 提供的服务化接口直接去装修相关的信息。