假设你对项目管理、系统架构有兴趣，请加微信订阅号“softjg”。增加这个PM、架构师的大家庭

一个站点就像一个人，存在一个从小到大的过程。

养一个站点和养一个人一样。不同一时候期须要不同的方法，不同的方法下有共同的原则。

本文结合我自已14年站点人的经历记录一些架构演变中的体会。

1：积累是不可缺少的

架构师不是一天练成的。

1999年，我作了一个个人主页，在学校内的虚拟空间，參加了一次主页大赛，几个DREAMWEAVER的页面。几个TABLE作布局，一个DB连接，几行PHP的代码嵌入在HTML中，再用FTP传到server上就能够给别人展示一个站点。

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开发project师，仅负责一个非常小的模块开发。但还是正式体会到一个大型系统的初创过程。这段时间对MVC的架构理论有了深刻的理解。MVC三层架构比2层架构带来的更好的技术扩展与团队扩展能力让我映像深刻。M层负责DB 逻辑的CRUD，架构师们开发出了大量的中间层JAR包，完毕了DAO层，DO的封装，M层也完毕了SERVICE层，完毕了BO的封装。接口包的封装。系统使用了最经常使用的工厂、单例、FACACE等模式（直到如今。我面试人还是经常仅仅会问这些主要的模式）。V层的模板隔离，前端开发能够在这一层和后端开发一起改动界面（之后，更大规模的团队连这一层都能够再分离）。

C层完毕输入输出的基本校验和检查然后调用后面的服务层功能或作转发。 简洁朴素的结构生命力是比較持久的。

直到如今，MVC还是具有非常强的生命力，在更种大型站点中承担重要架构骨架。

07年，我相应用层，服务中心层，持久层三层架构并没有多少的实践应用和理解。由于MVC对于初创系统或中小型站点。20人左右的团队规模来讲，已经适用。换个角度看，当时在3个月内作出一个完整的ERP系统也仅仅用使用MVC，再选进的架构也须要考虑站点发展的阶段。

用户一边使用。project师一边迭代改进架构，这个方式是作站点。不是传统应用软件开发。

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区会须要加大设置，否则easyOUT OF MEMORY。

加构师须要精读《数据库系统概念》这类书，对不同DB的索引原理和库表存储结构有了解，我们能够不是ORACLE ACE。但一定要听得懂ACE的DB架构和性能优化方面的建议。

而且在原则上，前端用户系统架构上不要出现直连DB的设计，这是亿级PV架构的基础设计保障，特别是一些营销类功能系统，短时并发大的页面不能有DB直连，一些小应用可例外对待。

架构师须要非常好的学习能力，技术是不断变化的。昨天用DUBBO，明天可能要换HSF。今天MEMCACHE。明天可能REDIS；今天刚刚把应用拆分，明天可能就要合并。公司外的技术社区还不断有一些好的开源中间件和框架出来，须要不断学习。关注。大站点的架构模式不一定合适小站点。新中间件和框架实施须要考虑运维成本和学习推广成本。架构上要选合适当前阶段的。

架构师须要和不同类型的专业人才沟通，所以要能高速理解并学习不同专业的知识去补充自身的知识结构不足。

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

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

3：设计理念

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

1>：异步换同步：系统中的非常多调用是能够异步化的，包含WEB界面上的AJAX异步，还有服务端的消息型异步；AJAX调用的应用要注意把这样的类型的应用集中到一个隔离的服务系统中。以方便在必要的时候进行服务降级。

AJAX调用一般都是界面上非同步非强依赖的功能点；服务端异步的系统能够让服务端的请求RT变短，提升serverQPS。同一时候降低应用强依赖。

一个小型系统（峰值万级消息per second）的服务端异步消息能够借助RMDB的表实现，当站点规模变大时（峰值百万级消息每秒），消息系统须要有一个中间件，负责消息持久化及数据 CRUD管理；再大点的时候，消息中间件的分布式与可用性会有更高要求，须要综合使用多种架构设计理念；

同步换异步对软件project上的优点是。能够把一个子系统的不同模块分别由不同的人开发维护。调试期间，两个模块也不会有非常强的依赖。

提高开发并发性。

2>: 集中变分布：

一个站点小的时候，非常多业务都会在一两个应用系统中实现。比方一个电子商务站点。从登录，到首页，到搜索，到产品DETAIL，到购物车。下单支付。风控，订单管理，用户中心到售后用户纠纷流程。站点小的时候，这样的一体化的业务架构模式在站点规模小的时候，不管是研发团队规模还是硬件成本都是比較低的。这个时期的扩展性一般仅仅须要作到LB后面挂一片集群。

server资源利用率这时候也是比較高的。

随着业务规模扩大，须要把系统独立分拆出来。基本原则是：不同维护策略和服务等级的页面和服务 不要放在一个应用容器中，最好不要放在一个虚拟机或物理机上。发生过非常多次紧急事件。由于大流量页面上带着一个小的AJAX请求，把提供AJAX服务的 WEB应用压死。

而这样的AJAX应用平时又是比較easy在容量评估的时候被忽略的。也比較难以管理AJAX，由于一个前端开发project师非常可能由于一次小的运营活动加上一个调用。server端不同服务类型的功能也须要分拆到不同服务中，服务的聚合一定要有一定的原则，并不断的调整治理聚合服务内容。

假设把一个文件生成类的业务功能（比方用户批量导入导单）和一个下单的服务放在一起，非常easy让下单这类核心主干逻辑功能受批量导出功能影响。当架构师须要作服务降级时，不得不侵入代码层作服务功能的隔离。

架构上的基础设施也须要有隔离策略。

比方一个功能先后须要完毕读数据，再生成文件，再发消息，再写数据库，写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和网卡口子的状态；一类是基线型，能够看到每小时。分天同一个指标的变化历史。看到一个页面响应速度。serverRT时间的变化。一类是关键业务逻辑结点的按需统计，比方须要看一下某页面修改后某个页面点击量和原来的区别。

监控会带来系统的性能损失，特别是在线打点，无论你是在容器层面作的，还是在业务逻辑侵入方式实现的；另一种是通过日志分析。可能实时性差一些，比方有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：软件project

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

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

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的，能预见问题或提前准备的架构师是称职的，这才是技术促进业务。

假设你对项目管理、系统架构有兴趣，请加微信订阅号“softjg”，增加这个PM、架构师的大家庭