大型网站技术架构-第4篇 架构师
读书笔记 摘自：《大型网站技术架构：核心原理与案例分析-李智慧》
14 架构师领导艺术
架构师是软件开发组织中一个比较特殊的角色，除了架构设计，软件开发等技术类工作，通常还需要承担一些管理职能：规划产品路线、估算人力资源和时间资源、安排人员职责分工，确定计划里程碑点、指导工程师工作、过程风险评估与控制等。
还需要和项目组内外各种角色沟通协调，可以说架构师相当多的时间用在和人打交道上。处理好人的关系对架构和项目的成功至关重要。
14.1 关注人而不是产品
发掘项目组每个成员的优秀潜能，让大家理解并热爱软件产品最终的蓝图和愿景。每个人都是为实现自我价值而努力，不是为了领工资而工作。
这也是领导的真谛：寻找一个值得共同奋斗的目标，营造一个让大家都能最大限度发挥自我价值的工作氛围。
没有懒惰的员工，只有没被激发出来的激情。所有强迫员工加班的管理者都应该为自己的无能而羞愧。
14.2 发掘人的优秀
指望优秀的人来帮自己成事，不如做成一件事让自己和参与的人都变得优秀。
后来，这个同学不但找到了这个功能的开源实现，阅读了文档和代码，还针对我们项目的需求场景对代码做了优化，然后又将这些优化的代码提交给开源项目的作者，最后被合并到开源项目中。
大多数人，包括我们自己，都比自己以为的更优秀，有些优秀需要在合适的环境中才会被激发出来，比如做一些有挑战的事，和更优秀的人合作，抑或拥有了超越自我的勇气。
14.3 共享美好蓝图
蓝图应该是表述清楚的
蓝图应该是形象的
蓝图应该是简单的
14.4 共同参与架构
- 不要只有架构师一个人拥有架构
- 让其他人维护框架与架构文档
14.5 学会妥协
不要企图在项目中证明自己是正确的，一定要记住，你是来做软件的，不是来当老大的。所以不要企图去证明自己了不起，永远也别干这种浪费时间、伤害感情的事。
架构师不应该对意见过于敏感，这时架构师应该做的是坦率地分享自己的设计思路，让别人理解自己的想法并努力理解别人的想法，求同存异。
对于技术细节的争论应该立即验证而不是继续讨论，当讨论深入到技术细节的时候也意味着问题已经收敛，对于整体架构设计，各方意见正趋于一致。
14.6 成就他人
架构师作为团队的技术领导者，在项目过程中不要去试图控制什么，带着一个弹性的计划和蓝图推进，团队会管好他们自己。
15 网站架构师职场攻略
网站架构师人在职场，需要处理好个人、团队、公司的利益。需要不断地在工作中发现问题，解决问题，提升工作经验、知识技能和核心竞争力，扩大自身影响力，达成工作绩效。
15.1 发现问题，寻找突破
新员工首先要做的事情是融入团队，跟大家打成一片，只要能和团队一起共进退，你就不是一个人在战斗。等熟悉了情况，知道了水的深浅后，再寻找突破口，择机而动。
在新环境中一时施展不开就怀疑自己的能力，进而担心被其他人怀疑自己的能力，于是努力想要证明自己，但是常常事与愿违，反而出乱子，伤害了公司和自己的利益。
15.2 提出问题，寻求支持
- 把“我的问题”表述成“我们的问题”
- 给上司提封闭式问题，给下属提开放式问题
- 指出问题而不是批评人
人在听到批评信息的时候，本能地想要去针对批评进行反驳或者辩解，于是谈话就变成关于批评是否合理的争论，离解决问题越来越远。 - 用赞同的方式提出问题
表达方式上要有所避讳，照顾到当事人的感受。
15.3 解决问题，达成绩效
- 在解决我的问题之前，先解决你的问题
先解决别人的问题有几个好处：
你帮别人解决了问题，礼尚往来，别人也会帮你解决问题。在帮别人解决问题的过程中，熟悉了情况，后面解决自己的问题也就得心应手了。
解决别人的问题时使用的是你的解决方案，这个方案在你的控制之中，将来往这个方案里再塞一些东西解决自己的问题，手到擒来。 - 适当的逃避问题
对于这种情况，适当逃避问题，将事情搁置起来是最好的办法。
“我去开个会，我们回来再谈。”“这个idea非常好，我们改天组织一个会议好好讨论一下……”
16 漫话网站架构师
对于公司，架构师引领公司的技术方向，架构师的眼界和高度决定了公司的技术高度；对于技术团队，架构师的决策和技术方案影响工程师的开发模式和工作量。一个称职的架构师是公司的宝贵财富，而一个不合格的架构师可能会成为开发团队的梦魇，所谓将无能，累死三军。
16.1 按作用划分架构师
- 设计型架构师
- 救火型架构师
- 布道型架构师：但有时，由于自身的局限或者不能跟上技术潮流的发展，会成为忽悠型的“大师”、偶像派的专家。
- Geek型架构师
16.2 按效果划分架构师
- 夏尔巴人架构师
- 斯巴达人架构师：斯巴达人架构师带给项目组的，不只是技术和方法，更重要的是必胜的信念。这种信念是架构师自己积累起来的气场和影响力。
- 达官贵人架构师
16.3 按职责角色划分架构师
- 产品架构师
- 基础服务架构师：在大型互联网应用中，基础服务承担着海量的数据存储和核心业务处理服务，有许多挑战性的工作。
- 基础设施架构师
16.4 按关注层次划分架构师
- 只关注功能的架构师
- 关注非功能的架构师：除了产品功能，架构设计也关注性能、伸缩性、安全性、可用性、系统未来的扩展性，以及上线后易于运维管理、监控报警、故障修复等非功能目标。
- 关注团队组织与管理的架构师
- 关注产品运营的架构师
- 关注产品未来的架构师
16.5 按口碑划分架构师
- 最好的架构师
- 好的架构师
- 一般的架构师
- 差的架构师
- 最差的架构师
16.6 非主流方式划分架构师
- 普通架构师
- 文艺架构师
- 1+1架构师：此类架构师喜欢在架构设计中堆砌概念和模式，设计文档宏大而不着调，面面俱到却不解决具体问题，说起来头头是道却不知如何落地。其根源不是不了解真正的问题就是不掌握正确的方法。有时候也不排除这样一种可能性：做架构设计的目的是为了炫耀自己知道这么多术语。
附录A 大型网站架构技术一览
前端架构
前端指用户请求到达网站应用服务器之前经历的环节，通常不包含网站业务逻辑，不处理动态内容。
浏览器优化技术
CDN
动静分离，静态资源独立部署
图片服务
反向代理
DNS应用层架构
应用层是处理网站主要业务逻辑的地方。
开发框架
页面渲染
负载均衡
Session管理
动态页面静态化
业务拆分
虚拟化服务器服务层架构
提供基础服务，供应用层调用，完成网站业务。
分布式消息
分布式服务
分布式缓存
分布式配置存储层架构
提供数据、文件的持久化存储访问与管理服务。
分布式文件
关系数据库：通过在应用程序的数据访问层增加数据库访问路由功能，根据业务配置将数据库访问路由到不同的物理数据库上，可实现关系数据库的分布式访问。
NoSQL数据库
数据同步：为了减轻数据库压力，将数据库的事务日志（或者NoSQL的写操作Log）同步到其他数据中心，根据Log进行数据重演，实现数据同步。后台架构
网站应用中，除了要处理用户的实时访问请求外，还有一些后台非实时数据分析要处理。
搜索引擎
数据仓库
推荐系统数据采集与监控
监控网站访问情况与系统运行情况，为网站运营决策和运维管理提供支持保障。
浏览器数据采集
服务器业务数据采集
服务器性能数据采集
系统监控
系统报警安全架构
保护网站免遭攻击及敏感信息泄露。
Web攻击
数据保护数据中心机房架构
大型网站需要的服务器规模数以十万计，机房物理架构也需要关注。
机房架构：数据中心能耗问题已经日趋严重，Google、Facebook选择数据中心地理位置的时候趋向选择散热良好，供电充裕的地方。
机柜架构
服务器架构
附录B Web开发技术发展历程
CGI（Common GatewayInterface，通用网关接口）
CGI技术（广义上也包括Java Servlet）被称作脚本模式，CGI程序需要解析HTTP请求，处理业务逻辑，并在输出流中构造响应信息的HTML。
开发人员可以在HTML中嵌入程序代码。这种模式被称作服务器页面模式。直到现在，PHP仍然是许多中小型网站建站首选技术，和Apache、MySQL、Linux共同组成一个强大的Web开发平台，被称作LAMP。
使用MVC模式可以很好地分离模型与视图，使二者完全解耦，互相影响降到最低。
Web开发中通常将服务端划分为三层：表现层、业务逻辑层和数据源层。表现层完成视图展现和用户交互；业务逻辑层实现系统的核心逻辑；数据源层负责数据存储、交换和通信。这种层次划分是逻辑上的，物理部署上多个层会作为一个应用部署在一起。
后记
大型网站不是设计出来的，而是逐步发展演化出来的。
互联网没有门槛，谁都可以进来玩，但是进来后，最好把那些陈旧的思想和包袱放下，重新来过。
互联网是一个开放和分享的世界，这里是创新者的乐园，探险者的处女地。
互联网是一种精神，一种开放、分享、自由的精神；越是付出不问回报，越是获得丰厚的回报；越是不设边界，越是拥有整个世界。互联网是一种颠覆，打碎所有的藩篱，给所有人平等表达和获取的机会，每个人都可以发出自己的声音。
互联网正在并将继续改变这个世界，一切才刚刚开始，你我正生逢其时！
===========文档信息============
读书笔记由博主整理编辑，供非商用学习交流用
版权声明：非商用自由转载-保持署名-注明出处
署名(BY) ：dkjkls（dkj卡洛斯）
文章出处：http://blog.csdn.net/dkjkls