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。
