来源：叶军博客html
一个网站就像一我的，存在一个从小到大的过程。养一个网站和养一我的同样，不一样时期须要不一样的方法，不一样的方法下有共同的原则。本文结合我自已14年网站人的经历记录一些架构演变中的体会。前端
1：积累是必不可少的
架构师不是一天练成的。html5
1999年，我做了一个我的主页，在学校内的虚拟空间，参加了一次主页大赛，几个DREAMWEAVER的页面，几个TABLE做布局，一个DB链接，几行PHP的代码嵌入在HTML中，再用FTP传到服务器上就能够给别人展现一个网站。python
2000年，我的主页已经不能知足好奇，在当时的网管中心管起几台机器，做起网线水晶头，用ALL PEOPLE SEEMS TO NEED DATA PROCESS的理论开始认识了7层网络模块（面试技术员工时，常常会问这些网络基础知识的理解）。有了基础理论的武装，我也开始配置各类服务来玩LINUX，AIX和FREEBSD这些系统。面对各类原理不懂的系统，目的只是想尽办法去解决网站须要的各类基础服务。当时搭建了REALSERVER流媒体服务，各类开源FTP下载服务，BATTLENET游戏网关，APACHE（keepalive等配置，http报头相关的知识 也是面试的老客户），DNS，QMAIL等服务给学校的学生使用；mysql
网站有近10万PV的时候，开始考虑如何做扩展拆分，MYSQL的MASTER SLAVE做读写分离，MYSQL的索引优化是当时惟一会使用的DB性能优化方法。这个阶段基本上能解决需求，同时也遇到瓶颈，不知道访问量再大一个数量级，怎么办?明显感到技术能力不够。当时受限于网站的量一直没有新的数量级的突破，致使了几年内技术工做以维护为主，体验着网站平常运维的各类纠结，体力活。而这时期网站的2层架构方法也一再被重复应用到后续的N个网站的搭建过程当中，2001年开始的JSP与PHP之争好像对我没什么感受，由于我仍是只会用那种很土的2层架构做着网站：页面中嵌入JSP，链接后端的MYSQL进行数据的CRUD，没有事务，没有考虑数据库读写错误，没有考虑两层系统不可用，由于有问题只须要重启，有报错只须要改JSP后刷新页面。做网站确实是体力活。linux
2005年，在道富参与了FXCNG项目，用MULE ESB，接触到MULE的前几个月尚未意识到这个系统在架构中的位置。直到半年后，在与第三方系统集成的应用中，才发现，这样的一个系统就是传说中的中间件，他能够专业的解决一部份系统的职能，好比当时的消息和远程调用代理。这时候我逐步有了一些架构观点，一个大型的应用系统中，是须要隔离一部份技术职能，让系统责任单一，方便技术维护和团队扩展，专人办专事。android
2006年，阿里软件，一个全新的开始。进入阿里软件的前三个月在马总的老家，淘宝的发源地：湖畔花园小区，2楼的4室两厅里进行了封闭式开发，很累，但很兴奋。这段时间，我参与了一个全新外贸ERP系统的搭建。虽然只做为一名普通的JAVA开发工程师，仅负责一个很小的模块开发，但仍是正式体会到一个大型系统的初创过程。这段时间对MVC的架构理论有了深入的理解。MVC三层架构比2层架构带来的更好的技术扩展与团队扩展能力让我映像深入。M层负责DB逻辑的CRUD，架构师们开发出了大量的中间层JAR包，完成了DAO层，DO的封装，M层也完成了SERVICE层，完成了BO的封装，接口包的封装，系统使用了最经常使用的工厂、单例、FACACE等模式（直到如今，我面试人仍是经常只会问这些基本的模式）。V层的模板隔离，前端开发能够在这一层和后端开发一块儿修改界面（以后，更大规模的团队连这一层均可以再分离）。C层完成输入输出的基本校验和检查而后调用后面的服务层功能或做转发。 简洁朴素的结构生命力是比较持久的。直到如今，MVC仍是具备很强的生命力，在更种大型网站中承担重要架构骨架。ios
07年，我对应用层，服务中心层，持久层三层架构并无多少的实践应用和理解。由于MVC对于初创系统或中小型网站，20人左右的团队规模来说，已经适用。换个角度看，当时在3个月内做出一个完整的ERP系统也只用使用MVC，再选进的架构也须要考虑网站发展的阶段。用户一边使用，工程师一边迭代改进架构，这个方式是做网站，不是传统应用软件开发。ERP自己源自传统应用软件领域，咱们在用互联网的方式做管理软件，最大的挑战应该是这种边做边改进架构的理念。07年，这个理念之争逐步在团队内达成了一致，架构师们当心的平衡着业务和架构，这个网站高峰时，也支撑到了日访问量近千万的级别，没有闪架。git
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的，能预见问题或提早准备的架构师是称职的，这才是技术促进业务。