从100PV到1亿级PV网站架构演变

一个网站就像一个人，存在一个从小到大的过程。养一个网站和养一个人一样，不同时期需要不同的方法，不同的方法下有共同的原则。本文结合我自已14年网站人的经历记录一些架构演变中的体会。

1：积累是必不可少的

架构师不是一天练成的。

1999年，我作了一个个人主页，在学校内的虚拟空间，参加了一次主页大赛，几个DREAMWEAVER的页面，几个TABLE作布局，一个DB连接，几行PHP的代码嵌入在HTML中，再用FTP传到服务器上就可以给别人展示一个网站。
2000年，个人主页已经不能满足好奇，在当时的网管中心管起几台机器，作起网线水晶头，用ALL PEOPLE SEEMS TO NEED DATA PROCESS的理论开始认识了7层网络模块（面试技术员工时，经常会问这些网络基础知识的理解）。有了基础理论的武装，我也开始配置各种服务来玩LINUX，AIX和FREEBSD这些系统。面对各种原理不懂的系统，目的只是想尽办法去解决网站需要的各种基础服务。当时搭建了REALSERVER流媒体服务，各种开源FTP下载服务，BATTLENET游戏网关，APACHE（keepalive等配置，http报头相关的知识 也是面试的老客户），DNS，QMAIL等服务给学校的学生使用；
网站有近10万PV的时候，开始考虑如何作扩展拆分，MYSQL的MASTER SLAVE作读写分离，MYSQL的索引优化是当时唯一会使用的DB性能优化方法。这个阶段基本上能解决需求，同时也遇到瓶颈，不知道访问量再大一个数量级，怎么办?明显感到技术能力不够。当时受限于网站的量一直没有新的数量级的突破，导致了几年内技术工作以维护为主，体验着网站日常运维的各种纠结，体力活。而这时期网站的2层架构方法也一再被重复应用到后续的N个网站的搭建过程中，2001年开始的JSP与PHP之争好像对我没什么感觉，因为我还是只会用那种很土的2层架构作着网站：页面中嵌入JSP，连接后端的MYSQL进行数据的CRUD，没有事务，没有考虑数据库读写错误，没有考虑两层系统不可用，因为有问题只需要重启，有报错只需要改JSP后刷新页面。作网站确实是体力活。
2005年，在道富参与了FXCNG项目，用MULE ESB，接触到MULE的前几个月还没有意识到这个系统在架构中的位置。直到半年后，在与第三方系统集成的应用中，才发现，这样的一个系统就是传说中的中间件，他可以专业的解决一部份系统的职能，比如当时的消息和远程调用代理。这时候我逐步有了一些架构观点，一个大型的应用系统中，是需要隔离一部份技术职能，让系统责任单一，方便技术维护和团队扩展，专人办专事。
2006年，阿里软件，一个全新的开始。进入阿里软件的前三个月在马总的老家，淘宝的发源地：湖畔花园小区，2楼的4室两厅里进行了封闭式开发，很累，但很兴奋。这段时间，我参与了一个全新外贸ERP系统的搭建。虽然只作为一名普通的JAVA开发工程师，仅负责一个很小的模块开发，但还是正式体会到一个大型系统的初创过程。这段时间对MVC的架构理论有了深刻的理解。MVC三层架构比2层架构带来的更好的技术扩展与团队扩展能力让我映像深刻。M层负责DB逻辑的CRUD，架构师们开发出了大量的中间层JAR包，完成了DAO层，DO的封装，M层也完成了SERVICE层，完成了BO的封装，接口包的封装，系统使用了最常用的工厂、单例、FACACE等模式（直到现在，我面试人还是常常只会问这些基本的模式）。V层的模板隔离，前端开发可以在这一层和后端开发一起修改界面（之后，更大规模的团队连这一层都可以再分离）。C层完成输入输出的基本校验和检查然后调用后面的服务层功能或作转发。 简洁朴素的结构生命力是比较持久的。直到现在，MVC还是具有很强的生命力，在更种大型网站中承担重要架构骨架。
07年，我对应用层，服务中心层，持久层三层架构并没有多少的实践应用和理解。因为MVC对于初创系统或中小型网站，20人左右的团队规模来讲，已经适用。换个角度看，当时在3个月内作出一个完整的ERP系统也只用使用MVC，再选进的架构也需要考虑网站发展的阶段。用户一边使用，工程师一边迭代改进架构，这个方式是作网站，不是传统应用软件开发。ERP本身源自传统应用软件领域，我们在用互联网的方式作管理软件，最大的挑战应该是这种边作边改进架构的理念。07年，这个理念之争逐步在团队内达成了一致，架构师们小心的平衡着业务和架构，这个网站高峰时，也支撑到了日访问量近千万的级别，没有闪架。
08年，阿里软件开放平台，又是一个新系统。全新的系统架构总是可以得到足够的时间来考虑末来1到3年的增涨。实际上，互联网系统，我们感觉只能考虑到一年的架构。这一年，我参与架构设计，开始理解了三层架构的价值与扩展能理，服务中心开始搭建，因为这个系统将接受的几百万在线的旺旺用户访问，所以部份系统开始考虑服务中心，想把业务逻辑聚合到服务层，由统一的团队进行扩展维护。另外，随着两年下来小的业务系统越来越多，小机上的oracle连接数也吃紧了，服务中心的需求越来越大。首先进行的是用户中心，想法是集成整个集团队账号体系，基于『旺号』体系。这个用户中心项目有个响亮的名字：UDB，项目过程可以写一本书。这里不再展开。
《SAAS架构设计》这本书，针对的是软件平台的早期ISV用户。现在的眼光来看，这书写的过于简单，正如十年后再来看今天我的写的这个笔记一样。
09年，加盟了刚刚成立的aliexpress部门。经历了两三个应用的小系统到亿级PV的在线交易系统。遇到了很多问题，体会到一个小系统与大网站不同阶段架构的演变过程有不同的难处。

下文从不同维度分享亿级PV网站架构下我的体会和观点。

2：知识结构
网站架构师有很多，有科班出身的，有美术专业的，有生物专业的，有学物理的，有派出所警察出身的，我觉得都是OK的。我也接触到了这些架构师，非常有特点，在很多技术领域有自已专深的。英雄不问出路，好汉不提当年勇。架构师知识背景可以不同，个人看法是不同领域的人作网站架构可以带入很多交叉的思路。就像种树的人再去种花，其实也是可以看到一些共性的总结抽象。

网站架构师需要有编程的经验，从基本的算法，常用的设计模式，多线程开发，远程调用，不同类型数据源使用，这些是面试的时候看得基本功。我认为一个资深的测试专家一定是开发高手，一个架构师必须也是有长期的开发经验，很多性能优化是要从一行行代码优化起的。试想在一个被调用1000万次次每天的页面，一行代码如果每次都走到，每次少运算1ns,也可以节省不少的电力。我为环保作贡献，我骄傲。

网站架构师需要对网络环境有很好的知识理解。架构问题是需要考虑网络部署。比如系统因不可用而发生切换的时候，从一个机房切到另一个机房，要考虑网站的服务对用户访问速度上会有多大影响。这时候的技术方案可能是切DNS，也可能是切前端的跳转机，或是底层部份服务调用到另一个机房。对于这类切换的方案，架构师需要计算网络时间的开销带来的QPS影响，和用户体验上的延迟，每个请求估算需要精确到ms级。如果是全球范围内DNS切换，需要知道DNS刷新的时间经验周期，比如：全球更新在1小时左右，而80%的地区用户会在20分钟内刷新，这样系统带来的业务影响会有多大。

网站架构师需要对网络协议有深入的理解。HTTP协议是最基础的，无论是SESSION还是COOKIE在HTTP协议基础上怎么应用，COOKIE的大小，数量，浏览器是怎么处理HTTP协议的。这些基础有关键时候会影响业务的进行。比如，SAFRI浏览器对第三方COOKIE是禁用的，某功能跨域写COOKIE的时候每次都会重新生成COOKIE，直接导致系统统计用户UV的时候，数量增大，影响各种转化率的计算。HTTP协议还需要考虑本身的连接管理池大小和连接是否KEEPALIVE，这些细节很多时候成为架构上扩展能力的瓶颈。一个静态页面服务的HTTP MAXCLIENT设置 为2500，机器只有10台，很可能在一次中小型活动中连接数到顶，用户部份请求无法满足。

架构师需要考虑数据格式带来的性能影响。很多远程系统调用走的是HTTP协议为基础，数据格式为纯文本或JSON，或XML等，这类调用需要考虑数据的序列化和反序列化，这个工作是CPU开销型的，对性能优化上需要有针对性。QPS高的系统RT一定会短，但RT短的系统不一定比RT高的系统能表现更好的QPS。

架构师需要有很好的数学能力，计算一个QPS里系统从网络请求发出，到网络的IO时间，DB的磁盘读写时间，CPU运算时间，再到数据库连接数，数据分库分表容量规划，都需要有精确的计算。因为容量计算不正确带来问题也是非常多的。比如一台小机上ORACLE的连接数开了2000个，而应用系统由于不断的扩展，小业务系统不断加入，大型促销活动前，临时机器的不断上线，很快就把DB连接数用完，引起业务部份不可用。架构师需要去合理估算每种应用的服务能力，以及他对DB等资源的合理连接数。

加构师对JVM的内存分区及管理策略要有深入的了解，GC的频率可以发现很多系统容量的问题。一个OLD区不断加大的系统，伴随YGC高频发生，加上TCP机器连接数很可能高，可能是要是机器了。一个业务功能不断叠加的系统，很可能PERM区会需要加大设置，否则容易OUT OF MEMORY。

加构师需要精读《数据库系统概念》这类书，对不同DB的索引原理和库表存储结构有了解，我们可以不是ORACLE ACE，但一定要听得懂ACE的DB架构和性能优化方面的建议。并且在原则上，前端用户系统架构上不要出现直连DB的设计，这是亿级PV架构的基础设计保障，特别是一些营销类功能系统，短时并发大的页面不能有DB直连，一些小应用可例外对待。

架构师需要很好的学习能力，技术是不断变化的，昨天用DUBBO，明天可能要换HSF；今天MEMCACHE，明天可能REDIS；今天刚刚把应用拆分，明天可能就要合并。公司外的技术社区还不断有一些好的开源中间件和框架出来，需要不断学习，关注。大网站的架构模式不一定合适小网站，新中间件和框架实施需要考虑运维成本和学习推广成本，架构上要选合适当前阶段的。架构师需要和不同类型的专业人才沟通，所以要能快速理解并学习不同专业的知识去补充自身的知识结构不足。

架构师需要理解业务，在一些业务系统型的网站，业务架构师也显得异常关键，比如像交易型系统，支付型系统。业务架构师需要解决业务层次结构，业务边界划分，业务优先级与技术优先级的平衡。传统软件的系统分析师不知道是否也干这角色？但互联网的业务架构师要求更高，应该是建立在系统架构师的基础上再看高一层，通过业务和技术的综合影响力去帮助网站取得合理的架构，更好得拿到业务结果。

网站架构师的知识结构是宽又深的。

3：设计理念

每个架构师都会有一些自已原设计理念和原则。我的基本思路是：架构要作到至少1年的预见性（半年不叫预见性，因为方案实施要半年）。设计的目标是尽量让系统可以水平扩展，并利于。当然，有些业务处在生存的边缘，可能架构方案只有几个月的生命力。但一些成本不高收益稳定的架构理念，不管什么时候都是值得优先考虑的。以下是架构设计的一些常用手段。

1>：异步换同步：系统中的很多调用是可以异步化的，包括WEB界面上的AJAX异步，还有服务端的消息型异步；AJAX调用的应用要注意把这种类型的应用集中到一个隔离的服务系统中，以方便在必要的时候进行服务降级。
AJAX调用一般都是界面上非同步非强依赖的功能点；服务端异步的系统可以让服务端的请求RT变短，提升服务器QPS，同时减少应用强依赖。
一个小型系统（峰值万级消息per second）的服务端异步消息可以借助RMDB的表实现，当网站规模变大时（峰值百万级消息每秒），消息系统需要有一个中间件，负责消息持久化及数据CRUD管理；再大点的时候，消息中间件的分布式与可用性会有更高要求，需要综合使用多种架构设计理念；

同步换异步对软件工程上的好处是，可以把一个子系统的不同模块分别由不同的人开发维护，调试期间，两个模块也不会有很强的依赖。提高开发并发性。

2>: 集中变分布：

一个网站小的时候，很多业务都会在一两个应用系统中实现。比如一个电子商务网站，从登录，到首页，到搜索，到产品DETAIL，到购物车，下单支付，风控，订单管理，用户中心到售后用户纠纷流程。网站小的时候，这种一体化的业务架构模式在网站规模小的时候，无论是研发团队规模还是硬件成本都是比较低的。这个时期的扩展性一般只需要作到LB后面挂一片集群。服务器资源利用率这时候也是比较高的。

随着业务规模扩大，需要把系统独立分拆出来，基本原则是：不同维护策略和服务等级的页面和服务 不要放在一个应用容器中，最好不要放在一个虚拟机或物理机上。发生过很多次紧急事件。因为大流量页面上带着一个小的AJAX请求，把提供AJAX服务的WEB应用压死。而这种AJAX应用平时又是比较容易在容量评估的时候被忽略的。也比较难以管理AJAX，因为一个前端开发工程师很可能因为一次小的运营活动加上一个调用。服务器端不同服务类型的功能也需要分拆到不同服务中，服务的聚合一定要有一定的原则，并不断的调整治理聚合服务内容。如果把一个文件生成类的业务功能（比如用户批量导入导单）和一个下单的服务放在一起，很容易让下单这类核心主干逻辑功能受批量导出功能影响，当架构师需要作服务降级时，不得不侵入代码层作服务功能的隔离。

架构上的基础设施也需要有隔离策略。比如一个功能先后需要完成读数据，再生成文件，再发消息，再写数据库，写CACHE，再把数据同步到另一个机房。这一串逻辑中，除了异步化策略之外，还需要考虑一些基础职能的隔离，比如把生成文件的功能封装成一个服务，文件存储也需要从集中式变成分布式。T级可以考虑NAS类的集中式存储方案，P级和Z级的文件容量一般是需要考虑分布式文件系统方案，开源的也比较多。数据库与从集中式变分布式是现在流行的方案，之前我们小网站的时候常用MASTER SLAVE，然后再大点搞双MASTER写，多SLAVE读；再大点流量或者应用系统过多时，数据库的连接数也会受到考验，这时候分布式的分库分表方案是必须的。当然对架构师来讲，如果能用上一种云方案，不需要业务架构师考虑分库分表方案，那会更有幸福感。同步系统也需要考虑集中变分布的策略，两个机房或同一机房两个系统进行数据镜像同步，需要考虑多通道，分表，分字段，分库进行同步，有时候还需加入一些商业逻辑作为同步数据的判断。非镜像同步的时候，同步系统还需要考虑业务逻辑之间的事务特性。

3>: 架构层次化：

早期网站一般是两层架构，应用层+数据库层；现在大型网站经常采用三层架构，应用+服务中心+持久层，这三层分别在不断的增强可用性和可扩展性；理论上增强后的三层可以称为saas+ paas +iaas。
我把saas层看作现在淘宝开放平台上的第三方ISV应用，独立发展，互不影响，SAAS层数据隔离，运维隔离。SAAS层还可以自建分布式CACHE，集中式CACHE或简单的本机CACHE。电子商务网站本身的系统也可以把这个当成架构设计的目标之一，把自已的应用层作成像第三方APP一样的存在，这样发展效率和扩展性都会高很好。

paas层是我理解中的服务中心，具有应用逻辑的一个业务层服务中心，比如UIC用户中心，IC商品中心，TC交易中心等等 ，一般这样的一个服务中心会被多个上层SAAS应用所调用依赖。对一只被一个SAAS应用依赖的服务中心是否值得建立，这个要看投入产出比，一般小网站可以直接让应用连着DB，而中型网站也可以考虑在一个应用内部分为两层，先从JAR包层面隔离，PHP的话可以用代码目录结构上来隔离。网站更大规模的时候，1：1的依赖也是值得建服务中心的，因为这样可以隔离下面的持久层和上面的应用层，并且可以在PAAS层隔离考虑缓存等职能，可以考虑在这一层实现流控，隔离对DB连接数量的依赖。PAAS层要尽量实现自已的水平扩展，服务无状态。

iaas层负责实现持久层，一般数据源都在这一层，常见网站的数据源不外呼这四种：RMDB（这个玩转了近20年了），KV（最近10年比较热，KV可以分为内存型或持久型，对于持久型的KV，可以把数据挂到各类存储中），inverted index or file(倒排索引类），FILE SYSTEM（各类传统文件存储或自已实施的小文件中间件，普通文件中间件）。

这三次之间是1：1：1的关系建立，还是N:1:1，或是N：N：N，都是需综合考虑的。曾经有一次，我在设计一个系统的时候，为应用层界面设计了一个用户列表的头像显示功能就引发了一个调用比例考虑不全的重大问题。当时，用户有个旺旺的第三方游戏插件，插件主界面上有个好友列表，每个好友都有个头像读取的请求。假设用户每天9点左右登录旺旺的人中会有10%的人马上去玩这个游戏，9点左右在线按100万人算，每个人的好友有平均50个，则每天9点左右用户头像URL的HTTP请求量会有50*10万，产生近500万个突发的HTTP请求。虽然有CDN，依然存在很大的头像请求容量的不足，并且服务端获取用户好友列表信息的接口调用并发量也会很大，如果没有提前对第三方应用进行接口调用限制和设计上的规范化，调用比例很可能带来极大的系统伤害。
应用层与服务层之间的调用与依赖会随着网站规模变得越来越复杂，当网站小的时候，这两层直接的固定协议调用是可以接受的，调用方知道服务端的IP LIST，也知道调用的SOCKET，还有调用的协议；规模更大的时候，调用变成N：N的方式，随然有层次，但已经成网状结构，这时候需要服务治理与服务依赖的监控，流控等基础设施。对于服务治理，引入服务中间件，比如阿里的DUBBO和HSF是比较成熟的可以处理每天亿级的服务调用量并作好配置维护，调用统计，分布式，名称服务，流控，路由等基础职责，业界开源的也有很多；服务层还需要处理异步消息调用与消息通知的机制，这时候需还要配全一些消息中间件。

4>: 功能分解化

网站的应用级功能在网站小的时候一般都在一个物理机上，但在网站发展过程中，有些模块经常因业务原因发生变化和升级，有些模块流量和调用量比较大，有些模块处理的及时性和异步性要求不同，有些模块与外部调用特别多；有些模块经常报异常，有些模块IO多，有些模块偏CPU计算型。不同的模块需要随网站规模发展进展不断的分解。

架构师之道在于庖丁解牛一般的理解业务系统的复杂度和结构关系，进行合适的分解和聚合，这是我理解业务架构的核心贡献之一。一个业务架构师首先是一个技术架构师，没有技术背景无法理解系统内的技术边界，没有业务能理无法预见架构变化的趋势，也无法预见业务系统的流量变化。

5>:服务中心化

服务化有很多方式，三层网站架构下，亿级PV的网站最好能把同一业务逻辑被多方使用，边界清楚的功能隔离出来作为服务。服务中心可以封装对持久层的访问，形成带有业务逻辑的一种原子性服务，加上一些事务性控制的多个原子服务。服务中心不要有界面，管理好服务的粒度，可用性，高并发下的性能，以及服务路由，监控为主要任务。

6>:结点监控化

亿级PV网站的监控是非常关键的，很多系统问题，服务问题，流量问题，性能问题，业务异动都需要通过监控来发现。监控可以分为几类，一类是快照型的，像搞活动的时候特别需要一个大盘监控。可以看全局的流量，交易量，访客分布，来源分布，系统LOAD，DB连接数，CPU和网卡口子的状态；一类是基线型，可以看到每小时，分天同一个指标的变化历史。看到一个页面响应速度，服务器RT时间的变化；一类是关键业务逻辑结点的按需统计，比如需要看一下某页面改动后某个页面点击量和原来的差别。

监控会带来系统的性能损失，特别是在线打点，不管你是在容器层面作的，还是在业务逻辑侵入方式实现的；另一种是通过日志分析，可能实时性差一些，比如有3分钟延迟；还有一类是基于RMDB直连的分析，一般会在备库上把数据导出来作分析，实时性好一些，但对备库或主库DB有压力。还有一类是基于消息的分析来实现监控。让一些关键结点有动作时，发现异步消息到消息队列上，然后监控系统的抓取模块和正常 业务逻辑一样去订阅消费这些消息。这种方式需要监控团队与业务逻辑有协同，这对长期运维有挑战。

4：基础架构

亿级网站的基础架构是较多时间投入的一个工作，小网站一般没有中间件的概念，基础架构投入精力不多，但一样可以运行的很好。对于小网站，DB也像是一个中间件。一个亿级PV的网站，要看PV，也要看UV。这两个数字的规模对系统的技术架构挑战点是不同的。PV流过的系统和UV经过的系统路径不同，比例可能也有所不同。

架构师需要分析这个路径，好比庖丁解牛般的分析。在合适的节点引入中间件。比如一个亿级商品量的系统，需要从商品的POST服务性能，图片存储空间，图片缩图处理服务，多语言商品信息翻译，商品信息与图片在不同系统之间同步的服务，图片CDN服务，商品信息更新的通知和提醒服务，商品搜索服务，商品统计类信息服务等不同阶段和信息模块的CRUD中引入中间件，让系统可扩展，可承受高并发。

在合适的时间点引入中间件提升架构水平扩展能力，只是关心可扩展是不够的。基础架构不只是要关心系统的可扩展能力，还需要关心可用性。系统达到亿级PV后，每停机1分钟损失的流量都都是很大的。系统架构师预见并规划好系统容量。对于预料之外的超过容量的PV进行服务降级，限流，针对系统不可用时提供组织保障机制，用提前制定的紧急响应流程让不可用时间尽可能变短，这也是很重要的架构师职责。异地机房容灾或是同一机房的系统切换也应该有定期不定期的演习。对于不同国家之间的机房灾备，系统必须考虑机房之间的调用延迟，国内同步系统一般在10MS之内的延迟是可以接受的，对于非同步系统，延迟可适当放大，这种延迟的时间需要根据业务特性进行评估。对于中美之间的200ms级别的延迟，系统需要有合理的评估，尽可能不要有中美服务同步调用。这个200ms的延迟来自网络物理传输，来自路由器路由算法的延迟，也有来自机房本地的信息号交换过程，是刚性的，很多大型电商网站都面临这一问题的挑战。EBAY， AMAZON，alibaba和GOOGLE这类的网站架构设计时，一定会有很多系统不得不讨论这一延迟带来的系统方案区别。有时候网站会因业务原因考虑建完全独立分站，有时候会灰这种架构问题的影响考虑作单写还是双写。如果是全球机房，则这一问题会变得更复杂。数据同步和分发会是一个关键的中间件和可用性设施。

性能是大规模网站的重要基础架构问题。网站应用层，我们关心系统的关键页面的QPS值，比如在100并发下，系统某页面能接受每秒几次正常调用；综合页面的QPS也是需要关注的，特别是当一个前台应用内的界面比较多的时候。WEB应用的QPS可以通过服务端日志中的COOKIE来回放，进行线上线下的压测来取得一个有信心的数字。前台的WEB应用原则上不要有直接的DB层访问，小规模网站者需要平衡投入产出比，有时候作一些TRADE OFF也是值得的。对于服务层的应用，一般关心TPS，因为调用都来自WEB应用系统，所以通过COOKIE回放这种调用是不可能。持久层的TPS和上两层的QPS，TPS量之间存在一个比例。多个数据库的TPS可能对应一个服务层的一个TPS。这对于系统的容量和机器的扩容估主也非常关键，需要维护这么一个状态的快照。架构师才能让这个状态时刻保持胸有成竹。发现关键资源瓶颈对于分析QPS和TPS是非常 关键的。

服务治理除了作抽应用层服务中心的工作和JAR包之间的依赖管理之外，服务强弱依赖也是需要有一个系统来监控和管理的。随时知道一个新上的系统在依赖哪个服务，或被哪个应用依赖，这是架构师工作的必要工具。架构师从输出经验，到提供工具平台，是一个必然的过程。小网站需要一个架构师的经验快速搭建，大规模网站则不可能靠一个人的经验来进行判断，需要更多的数据采集和分析生成规则。监控系统是一个网站健康状态的指示仪。

部署架构是网站进入10亿级规划，99.99%可用性要求下必然关注的问题。无论是EBAY还是AMAZON都在部署上有很多投入。单一的机房由于电力，机柜等问题，经常出现部署上的硬件约束；容灾与不同地区访问体验要求异地机房能提供在线同时的服务。部署上需要考虑是全机房的对称部署，或是应用不同分级的分区部署。比如持久层统一，服务层与应用层多机房对称部署；或是持久层与应用层服务层完全对称，但数据分区；这种分区需要考虑买家维度、卖家维度，或是IP区域分区，不同区生成的数据通过同步系统实现各区的最终一致。以订单为例，分区是可以让美国买家创新的订单写在美国分区数据持久层，然后异步消息生成同步任务，数据同步到卖家所在的分区。

基础架构的工作还有很多，架构师责无庞待。if not me, who?

5：软件工程

架构师除了作经验，工具和代码输出之外，还需要关注工作机制的建立和人员的传帮带。发布流程，可重复使用的灰度发布ABtest方案，代码管理规范，代码开发规范，人员梯队，业务优先级判断，中间件和平台化工作推进都是每一天的日常工作。有时候帮测式工程师去搭好并维护一套测试环境，也算是本职工作。

有些架构师被称为PM型架构师，也有被感觉像RA型的，偏咨询师型的架构，偏业务型的，偏算法型的，偏性能调优的，偏中间件和服务治理的，偏基础架构型的，这个是看网站发展阶段的需要，缺什么，作什么。关键是看架构在软件工程过程中对产品，对团队的输出是否能解决问题，拿到结果！eat what, what strong。

6：不同类型业务系统技术架构的差异化

每个网站架构都有不同，完全复制是不科学的。哪怕现在想再作一个淘宝网，光靠把淘宝全部几万台机器搬去是不行的，搭不出一个淘宝网。完全复制淘宝网的建设过程也不是靠谱的。可以复制或参考的是架构的原则和经验教训。不同类型的业务系统有不同的业务发展过程，业务架构发展演变过程不同；技术架构发展过程也不同，技术解决问题的重点不同，有些网站一开始需要解决的问题是如何从一个老网站中改版和分拆，有些则是全新的搭建。有些网站自建物流系统，有些则是与多家物流第三方对接系统。比如：有些网站交易模式简单，有些则需要去支持各种不同交易模式，像多次付款，预售，批发，团批，阶梯价格。。有些网站只需要解决支付 宝对接，有些则自建网银与支付系统，风控系统。

架构师要小心经验的惯性。大网站的方法不一定合适小网站。小网站的格局也不可能适用大规模。时代在变，地点在变，因时制宜，因地制宜。

7:小趋势的生命力

开放平台是胸怀: 06年，我们都谈开放平以。其实这个理念最初考验的是网站拥有者的胸怀。你是否愿意让其它人进来操作你的数据，是否愿意看到别人作出比你理好的应用层系统？甚至是一些服务层的系统？
FB与微博是社会化：07年，我们都讲SNS。SNS无处不在，因为他本质上是一个社会化的思路下的技术系统表示。愿意接受UGC，能否以社会化的方式让系统内的数据产生和管理发生。原意为这些社会化的小数据作系统，才可以最终生成大数据的拥有者。
电商团购是心理：09年，GROUPON火了，大家都团购。团购本身是没有什么技术创新的。有人说O2O是他的模式创新，可是，难道在原来的C2C网上不能实现吗？就像超市里把促销的商品放在货架边上的花车上，和放在货架里有本质区别吗？区别在于心理，用户体验上的区别。有时候这也会是一种竟争力，是一种常态化的经营思路，但不会主流。
移动PC平板是体验：10年，平板热。这种比手机屏大，比笔记本屏小的东西，满足了某些场景的方便性需求，体验创新很有机会。
Pinterest电商导购是基尼：11年，导购网站火了。瀑布流热了，国内的蘑菇街，美丽说火了。从根本上来看，导购是解决 了网站商品与用户流量之间的基尼关系，把基尼指数变得更小一些。否则80%的流量一直放在20%的热门商品和大卖家的店里，市场规模会有影响。作生态圈好一些，有活路的人多了，市场 才稳定。
外贸电商是库存：12年，外贸电商预热了，GOOGLE TRENDS里显示，才作两年的ALIEXPRESS的指数超过了DHGATE这个作了五六年跨境电商B2B网站，也越来越接近ALIBABA。COM这个老牌SOURCING网站。外贸从批发变小单是什么背景？我想本质上他的销售链变了。MIC基本还没变，没有变成快速反应能力的供应商，但出品商变成了拥有小单外贸客服能力的80后；进口商变成了国外的RETAILER，国外的超市变成了最终消费者。
体感外设是物联：13年，各类体感设备越来越丰富。什么手势，什么随身拍，什么位置设备，拍照设备。好玩。按马斯少理论来讲，工作是生存需求，买房子是安全需求，买车和大房子是社交需求，体现在的单位和职位是尊重需求，买体感设备，那是自我实现。

BARABASI预见了末来，小趋势改变末来的本质是一种叫幂律的无形之手，像我们所熟知的长尾。据说人类行为90%是可以预测的，人类的90%的形为是可以采集的。架构师从不同观察者的角度理解他们的观点有时候会有更多的预见性。

8：LAST BUT NOT THE LEAST

作网站如作人。架构的是人的骨架，人还需要配一个好的心态：心胸+态度。心胸是装进不同声音采集到信息的基础，态度是推广服务他人的手段。一个新架构方案下去，一定会有反对的声音。如何去说服别人现在就启动架构升级或转型方案，是需要带着心态去的。毕竟一个大的架构方案是需要很多人一起努力才能拿到结果，不是一两个英雄人物能造就的。架构师的工作方式是主动的，而不是问题驱动的。能解决问题的架构师是牛B的，能预见问题或提前准备的架构师是称职的，这才是技术促进业务。

没图片写贴子就是比较快？不过读起来是会费点眼力。