读书笔记 摘自:《大型网站技术架构:核心原理与案例分析-李智慧》
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