一，淘宝技术架构

 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提供的服务化接口直接去装修相关的信息。
ABTN

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）获取。  

 2.淘宝服务化架构：

用户：

淘宝用户分两类：买家和卖家，不过很多的卖家也会在淘宝买东西，所以他们既是卖家也是买家，因此最好是按照用户行为分：卖家行为和买家行为。买卖家行为都会涉及的系统包括：店铺，商城，交易，商品，社区等等。涉及到的功能有较大差异：
客户（卖和买）
店铺 商城 社区 商品 交易 无线 无名良品 前台系统：直接和用户打交道，它们依赖于各种心业务中心提供的服务化接口，淘宝服务 化 做的比较早，相对B2B来说比较成熟，这种高度服务化的方式有三点好处：

(1)搭建新应用很敏捷，所需要做的就是：整理业务流à 组装服务化接口à 渲染页面

(2)增强应用健壮性，只要保证服务化接口的稳定性容灾性，前台应用调用基本都不会有大的故障

(3)服务化接口把类似的业务接口抽象的很纯粹，使得性能观察和优化更有针对性，更专注！
SC[店铺中心]DC[装修中心 ]
TC[交易中心]UIC[用户中心 ]
RC[评价中心]
PC[促销中心]
Forest[类目体系]
IC[商品中心]
HSF[远程调用框架]

Tair[分布式 cache]

TDBM[数据库管理]

TFS[分布式存储]

Config[注册中心]
基础服务:提供最基础的共享服务，这些服务中心提供的功能基本与业务无关。 基本上这些服务在B2B都有，只是名字不一而已，大体的功能也类似，不过实现方 式有差异，会在下面具体做介绍。
商城搜索集市搜索 SPU搜索 实时搜索
搜索服务：提供前台和后台系统搜索服务

1.来源：数据主要来自上面的心业务服务接口，由业务接口通过tddl（淘宝的数据库分库架构类似 B2B的corba）同步数据到DB(oracle&mysql)，然后dump数据到搜索。

2.去处：包括两方面：前台—集市搜索，spu搜索，商城搜索，社区搜索等 后台--crm实时搜索，类目List等
核心业务服务：提供各种心业务模块的服务化接口，接口按使用方式分两类：

（1）通过HSF方式调用的远程服务化接口

（2）通过定期推送服务端数据文件到客户端的CS调用 图中：蓝色标注的系统的部分接口使用第二中方式调用，其他系统基本都是基于HSF方式的远程调用。
….
(1)卖家行为:主要定位在个人后台，且主要定位在后台的“我是卖家”TAB 页下的功能，包括：店铺管理，商品管理，订单管理，服务订
购和使用，广告系统，社区发帖，淘宝客等等，前台浏览相对使用较少。

(2)买家行为:集中在前台：店铺浏览，宝贝的浏览，社区浏览等比重较大，买家后台功能主要定位在后台的“我是买家”Tab 页下，包括拍
商品，付款，确认，退款，评价，社区互动等。
产品：淘宝对产品定义和 B2B 有差别，淘宝的业务拆分较细，服务化做的较成熟，所以前台应用对应的业务非常纯粹，如 Detail 系统可
能就一个 detail 页面，无数据库连接，所有数据来自底层的各种服务化中心，功能专一逻辑清晰纯粹，不过也正因为这，淘宝的一个产品
可能是分布在多个应用系统中，单个应用很难称为一个产品。
淘宝更喜欢用产品线的概念，往往是一个团队负责一条产品线，跨几个功能纯粹的应用, 如：商品线 交易线 店铺线 江湖线 商城线等。

二.淘宝服务化进程

 罗马非一日建成，上面看到的相对成熟的服务化中心也是在淘宝业在务发展过程中不断的遇到问题，解决问题的过程中沉淀下来的，下面给
大家简单图示下淘宝的服务化进程：  
  I．最初的淘宝应用架构状况：业务高度耦合，不同的功能模块基本都糅合在一个系统中，错综复杂，很有exodus2当初的味道啊！

2 II．随着业务发展，抽提部分核心业务之后的状态：

对前台业务做了切分，抽提了部分核心业务成为独立的服务化提供中心。不过抽提的
业务较少，这个阶段缺少对不同层的针对性优化，比如监控，容灾，事务等等

 III．大规模使用HSF，服务化相对成熟之后的状况：

前端应用高度分化，拆分成一个个功能单一的应用系统，后端服务化接口也划分的较
细同时针对不同业务和具体的技术实现做个性化优化，增强了各个节点的健壮性，高效性。

  通过上面的几张图可以明显的看出服务化给整个系统架构带来的好处： 

(1) 应用间的耦合降低，在服务化接口成熟的情况下，扩展新的业务需求变得方便，主要就是一个组合服务化接口的过程。
(2) 开发人员可以专心关注业务，而不用考虑分布式领域中的各种细节技术，例如远程通讯、性能损耗、调用的透明化、同步/异步调
用方式的实现等等问题。
(3) 各个系统负责的业务更纯粹，方便做针对新的性能调优和功能改进：如容灾性，并发，监控等方面的优化。这种针对性有助于增强
系统的高性能，高健壮。

三，淘宝服务化利器--HSF
  前台应用和心业务层由于和业务结合比较紧密，篇幅限制这里就不展开讲了，后续会有针对各个细节业务和技术的分享，下面主要说说服务化
中最重要的基础技术架构：HSF（淘宝远程服务调用框架），并附实例做说说它们的使用方式。

(1) HSF是神马？ [High-Speed Service Framework] 淘宝的高速远程调用框架，类似中文站的 Dubbo，基于 Mina 框架开发，它是淘宝应用从集中式走入
大型分布式的基础支撑。使开发人员无需过多的关注应用是集中式的，还是分布式的，可以更加专注于应用的业务需求的实现，这些纯技术
的需求都由HSF 来解决。

（2）HSF的系统架构       I. HSF交互场景图
客户端（消费端）从配置中心获取服务端地址列表—>和服务端建立连接开始远程调用—>服务端更新通过 notify（类似 B2B 的 naplio）
系统通知客户端。服务端和客户端都有对应的监控中心，实时监控服务状态。客户端，配置中心，服务端，notify，之间的通信都是通过TB Remotion
API 去搞定的。

---

阅读目录（置顶)(长期更新计算机领域知识）https://blog.csdn.net/weixin_43392489/article/details/102380691

阅读目录（置顶)(长期更新计算机领域知识）https://blog.csdn.net/weixin_43392489/article/details/102380882