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有压力。还有一类是基于消息的分析来实现监控。让一些关键结点有动作时，发现异步消息到消息队列上，然后监控系统的抓取模块和正常 业务逻辑一样去订阅消费这些消息。这种方式需要监控团队与业务逻辑有协同，这对长期运维有挑战。