【小土刀的剪报本】技术分册

这里是【小土刀的剪报本】的技术分册,主要是各类技术文章的节选和点评。


更新历史

  • 2017.02.23: 第四次更新
  • 2016.12.30: 第三次更新
  • 2016.12.11: 第二次更新
  • 2016.11.18: 第一次更新

高屋建瓴

确定重构的目的和必要性。检查清单: 架构重构的原因是什么,是为了满足业务的需要还是只是觉得架构不好看? 除了架构重构之外,还有其他备选方案吗?是否都分析过这些方案的利弊?

定义“重构完成”的界限。检查清单: 重构的目标可以量化,或者说可以测试吗? 重构完成的标准是什么?得到业务部门或者领导的认可了吗?

渐进式重构。检查清单: 能否把重构过程分成小的迭代,每一次改进都能尽快得到反馈? 重构过程中的效果能够定期展示给业务部门或者领导吗?

确定当前的架构状态。检查清单: 你了解当前的架构设计吗?它的设计初衷和之前的选型方案知道吗? 你能给架构设定一个基准状态吗?

不要忽略数据。检查清单: 业务数据的需求在重构设计中有体现吗? 重构过程中能否通过实际数据来验证效果?

管理好技术债务。检查清单: 团队对技术债务有跟踪和备忘录机制吗?还是开发人员可以随意的产生债务? 针对技术债务有定期的培训、回顾机制吗?

远离那些虚荣的东西(例如使用“热门”的技术栈)。检查清单: 重构的技术选型是否有详实的数据和专家评估? 选用的技术是否有良好的人才积累和足够的经验支持?你是不是实验小白鼠? 在技术选型时,是否至少有两个方案待评估?有没有成熟的技术方案?

做好准备面对压力。检查清单: 架构的重构是否得到了管理层(特别是最高管理层)的支持?他们是否对重构的时间、任务量有直接的认识? 你的重构计划中是否包含了一些可以量化的成果?是否定期向管理层展示这些成果?

了解业务。检查清单: 是否与业务部门就架构重构所能实现的业务目标进行过充分的讨论和确认? 是否对关键业务和优先重构的业务进行了确认?

做好面对非技术因素的准备。检查清单: 当非技术因素影响架构的重构时,你是否对目标做了调整并告知了利益相关各方? 你是否准备以开放而不是抵制的心态来对待非技术因素的影响?

对于代码质量有所掌握。检查清单: 团队成员是否对代码质量有足够的重视?是否有奖惩措施? 团队内部是否有代码质量的标准文档和审查流程?

让团队做好准备

来自《架构师重构代码的12条军规》

最近也在做代码重构的相关工作,感觉是一个不容易做好的大事情呀

第一, 规划和敏捷要并重 。敏捷和规划不是冲突的,应该要完美契合在一起。尤其做技术管理的,一定要时刻拿捏度,管控规划要做多大,敏捷多少要放开。 第二, 人的观念转变最重要 。业务产品技术的划分,最关键的还是要找到正确的人,一个好用的人抵过不好用的人10倍。 第三, 要激发团队的主观能动性 。规划往往会抑制团队的主动能动性,但敏捷容易制造混乱。很多人离职不是因为薪资,可能是因为成长的空间不够大,做的工作看不到价值。怎么让一个人可以拥有十年的工作经验,而不是只有一年的工作经验使用了十年,这是管理者或者技术管理者不停要思考的问题,管理者需要和团队一起成长。 最后, 业务发展最重要 ,信息必须要很好支持业务。

来自《传统企业如何转型互联网?苏宁六年技术架构的演进总结》

这个其实在大疆也是如此,这个我需要好好实践和领悟。

其实从美国来看“云”的分工已经很细化了,比如说美国的AWS,看上去它的服务包罗万象,实际上就三大块: 第一,对象存储S3。对象存储解决的是非结构化数据存放问题。其实AWS的第一个产品就是对象存储,这也是AWS最牛的产品,它与客户产生了极高的黏性。比如赫赫有名的DropBox背后完全是 Powered by S3。 第二, EC2。它属于IaaS,IaaS代替的是硬件行业,比如说IBM、HP、SAM、DEC、康柏、DELL 等等。 第三,Orchestration编排服务。是对传统中间件(如数据库、运行池等等)高度自动化管理和运行的过程。

来自《2017年,关于云计算未来发展的三个预测》

这个总结的很精辟,基本上能够使用到的服务,都在这里面了。


今天中国有一次机会,今天可能世界上第一台计算机不是发明在中国,今天可能最好的CPU也不是在中国,但是中国有可能变成世界上第一个国家,能够真正把计算变成一个公共服务,它对于将来二十年、三十年中国及世界的影响是巨大的。

好时代的三个宝贝:互联网、数据、计算

为什么要感谢互联网,大家千万不要在互联网前面加一个字,不要再互联网后面加一个字,不要有人在前面加一个移动互联网,互联网还是互联网,互联网对我们的影响太大了,大到一百年以后,大家还离不开它,还会受它的影响,这是我讲的第一个感谢,因为今天有互联网,它变成了基础设施。 第二件事情,大家要感谢因为互联网出来,有一个东西出来,叫做数据,数据是人类在发现土地、石油以后的另一类巨大的资源,这个资源的发现可以跟人类第一次利用好土地,人类第一次利用好事有,人类第一次知道怎么使用煤相提并论,人类完完全全用了一个新的资源,而这个资源是人本身创造的,不是上帝赐给我们的。 第三个,人类从此从计算机时代走进了计算时代,这个话怎么讲,你要想用计算的好处,再也不用抱着一台计算机回去了,今天一个学生,哪怕你不在实验室,不会因为实验室的老师给你多一百台机器而多干一点,你只是因为是学生而没有资源了,计算给你巨大的可能性让你去发挥创造才能。

来自《中国,是时候为世界技术做出贡献了》

这也是我的态度,所以我想要做开放的云计算课程,因为技术的竞赛实际上就是人才的竞赛,我们需要更多的人,来冲上这一次时代改变的浪。

团队建设

常见经理人有两类: (1)“铁腕”经理人:过于关注结果,能让组织获得成功,团队成员却离他而去 特点:保证权威性,现实,精明的安排,关注结果 (2)“好人”经理人:过于关注人,拿不到好结果,团队成员觉得他是好人 特点:民主,支持下属的大部分决定,人情味 有没有“高效”经理人,即能拿到结果,又能建设好极具战斗力的团队,是原书要讨论的内容。

一分钟目标是指,每个组织的目标极其评价标准不宜超过250个字,以便一分钟之内能够读完这个目标。清楚目标之后,一切就清楚了,所有人可以根据目标来定期检查工作进度。

好的经理会通过观察员工,通过发现员工做对了什么,帮助他们充分发挥潜能。很多经理总在为员工挑错,而高效的管理者会在员工刚进入一个团队时,对于他们做得好的事情,及时给与简短的肯定:新人很容易知道,在团队中哪些是被鼓励的,具体的示例很容易让人知道肯定是真心的,而不是泛泛而谈“你今年表现很不错”。

只要在初期,接手一个新团队,进入一个新职位,负责一个新项目时,让员工保持做正确的事情,保持一个好的节奏,未来的良好工作习惯会成为自然。

来自《一分钟经理人》

管理这种跟人心打交道的事情,就像艺术一样,有太多需要实践和摸索的地方。


在我看来,这个世界上有三种商业公司:

运营或销售驱动型的公司。这类的公司以运营和营销见长,技术对于他们来说,更多的只是为了支持大规模的营销活动,以及成本上的控制,所以,基本上来说不太需要技术创新。这种公司最大的问题就是缺乏安全感。

产品驱动型的公司。这类公司以产品见长,通过创造能提升用户生活体验的产品见长,技术对于他们来说,除了支持大规模的在线用户之外,他们会更多的去寻找那些为了增强用户体验,提高整个业务流程效率的技术创新。比如:UI的交互方面的,整个业务流程方面的。这种公司最大的问题,就是容易被别人模仿和抄袭。

技术驱动型的公司。这类的公司相信技术能改变世界,他们更多的是用强大的工程技术来创造有颠覆性的东西,更多的是用各种自动化的技术取代人类。比如:近代的蒸汽机技术取代了大量的人工,数字技术取代了大量信息传递的人工,现代,这类公司还希望通过人工智能来取代愚蠢的人类来做决定。这种公司最大的问题就是可能做出叫好不叫座的东西。

工程师文化就是自由加效率!

不害怕错误。处理错误的正确的姿势是分析总结教训,而不是惩罚故障人。前者让人改善进步,后者让人萎缩不前。最大的错误就是不敢犯错,最大的问题就是不敢直面问题。 宽松的审批系统甚至没有审批系统。审批通常暗示着三件事,1)对人的不完全信任,2)繁琐的流程,3)思维上的束缚。这些都是创新和想像力的天敌。一个公司的监管、审批、流程越重,这个公司的活力也就越差。

避免无效率的组织架构和无效率的管理。这体现在这些方面:1)扁平化的组织架构,2)努力用自动化工具取代支持型的工作,3)不超过10个人的全栈小团队,4)不按人员的技能分工而是按其负责的产品或功能分工 5)开会不是解决问题,开会是表决提案,6)通过产品的目标或信条Tenets来减少沟通和决策过程

不断的提高标准以及招聘最好的人。取法其上,得乎其中,取法其中,得乎其下,取法其下,法不得也。如果一个公司或一个团队想变得越来越好,越来越强大的话,就必需要不断的提高自己的工作标准,提高工作标准意味着要不断地培养和招聘更好的人。在Amazon和Google的招聘官中都有一个叫Bar Rasier的人,这个人就是为了提高招聘标准而设立的。

创建一个持续改善的文化。一个好的组织,一个好的团队,是需要不断反思前进的,这需要全体员工一起来的。微观层面上,在项目做完后需要有一个总结会分析项目中的得失,在故障出现后,需要有故障分析会,反思得失,在Amazon,严重的故障,需要写一个COE(Correction of Errors)的文档,其中有一节叫“Ask 5 Whys”,让你自己问自己至少5个为什么。

通过政治手段:你需要把住三个地方——招聘、绩效考核 & 升职。比如,你要落地工程师文化中的简化和自动化,那你你在招聘的时候,你需要把懂简化和喜欢自动化的人招进来,然后在绩效考核和升职的地方设置上一条硬性指标——你今年简化了什么?自动化了什么?如果没有,对不起不但不能升职,绩效可能还不达标。

通过经济手段:让不做这事的成本 > 要做这个的成本。然后,正常的人类都会选择成本低的方案。比如,如果你要推行Design/Code Review/UT以提高质量,你就把QA和OPS团队全挪到一边去,让Dev团队自己测试,自己负责。

工程师文化要落地,还有几个小条件, 第一,团队要小,Ownership很重要,Eat Your Own Dog Food。 没有人帮你擦屁股,自己的屎自己吃,没有痛苦,不会产生想进步的动力。 第二,热爱学习和尝试,学习尝试新的技术,开拓眼界,学习尝试新的思维方式,否则,呆在原地,原有的思维方式只会让你在原地打转转。 第三,老板更多的相信技术而不是管理。相信技术会用技术来解决问题,相信管理,那就只会有制度、流程和价值观来解决问题。

出自《左耳朵耗子:什么是工程师文化?》

打造一个好的团队太难,但是一旦成功,就是大大大大的财富了。


对于技术团队来说,“管理”当然必不可少,但“领导”显然更加重要。对优秀的技术团队来说,虽然它解决的不是重复的问题,但工作效率一定是越来越高的,不可能也不应该原地踏步,做到这一点离不开个人和团队的成长。

个人对于技术有不同的习惯和看法,这很正常。但是如果大家在一个团队内工作,这个团队就必须有共同的工作习惯、方式、价值观,身为技术领导,必须有能力、有动力去及时解决这些问题,保证团队从代码规范到架构设计等等问题都有明确决策,帮助大家树立共识并督促执行,同时化解个体的反感——这份工作很不好做,但不得不做。

来自《“技术领导”不等于“技术管理”》

团队的风格建设其实非常重要,正如文中所说的那样,一致且清晰的观念是非常强的上下文,能够极大降低沟通与合作成本。另外就是如何在死的制度和活的人之间找到平衡,很不简单。

技艺修炼

数据科学的特点在于跨界: 思维⽅式的跨界:融合各种学科的思维范式,例如统计的演绎推断和机器 学习的归纳; 技术⼯具的跨界:前后台⼯具和数据分析工具的全面使用; 业务能力的跨界:商业问题—数据洞察—解决方案—数据产品的全面了解。

从职业主线来看,和数据相关的职业(仅限商业公司)有四大类: 第一类是产品。侧重于底层数据框架搭建,数据报表开发,数据产品开发,例如淘宝数据魔方的开发,这类工作需要很强的软件开发背景。 第二类是模型。侧重于对数据的研究,用统计理论或机器学习的方法对数据进行分析建模,例如广告的点击率分析建模,这类工作需要丰富的统计理论和模型算法知识。 第三类是美学。侧重于对数据的创作,用 web 技术进行数据可视化或者制作信息图,例如《卫报》的数据网站,需要很强的可视化能力和前端技术。 第四类是价值。侧重于研究数据的商业价值和战略规划,强调对专业领域的业务理解和交流沟通,例如咨询公司发布的商业分析报告,需要广泛的业务知识和商业敏感度。

来自《肖凯:数据科学家是如何炼成的》

最近在做第一类和第二类工作,希望能够把后面两类的任督二脉也打通


分享的成功,不只决定于你有多少知识,你为分享做了多少准备,还决定于你能在多大程度上跳脱出来,把重点从“我要讲”转移到“我想听”,按照听众最容易接受的方式来展开演讲。按照我的经验,凡是从这个角度出发展开的演讲,通常效果不会太差。

有次一位女性朋友问我:为什么LED灯越来越流行了?我脱口而出的答案是“因为LED发光效率高”。我原以为自己的答案很容易理解,没想到最终解释了半天,还被人家一句话气个半死——“不就是省电嘛”。这个例子我印象很深,在我的潜意识里,“发光效率高”就是习焉不察、不必解释的概念,但是对她来说,“更省电”的说法明显更容易理解。如果我的目的是向她解释,而不是给人上课,那么“省电”明显优于“发光效率高”。

来自《要做好分享,须有演员的修养》

说话是一门技术活!


架构是什么?架构是在充分理解、认识、分析问题的基础之上,在了解各种约束条件的前提下,合理选择搭配已有的资源,最终得出兼顾各方利益的解决方案。在软件行业,我们要认识和分析的问题必然离不开软件开发,能动用的资源也离不开软件开发,所以“架构师不碰代码(和开发)”绝对不是正常现象。

要想学习架构,从仔细理解自己手上的工作开始 前面说了,架构是要建立在充分理解、认识、分析问题的基础之上,和了解各种约束条件的前提之下的。无论理解、认识、分析问题,还是了解各种约束条件,都是需要持续锻炼才能培养出的能力,而且是必须从小到大、从简单到复杂循序渐进的。 即便你现在没有做“架构”的工作,也不会有人阻止你分析自己的工作,问自己一系列问题:这些工作分为哪些部分?这些部分之间的关系是怎样的?哪些是互相隔离的,哪些是彼此关联的?谁依赖谁?谁应当先做,谁应当后做?每个部分的重要性是怎样的?为什么定出这样的重要性?某个看似难以理解或者不合理的现象背后的原因和决策链条是怎样的?

无论多么复杂多么高级的软件系统,架构都离不开细致的分析,都离不开关心上述问题:系统可以分为哪些部分?这些工作分为哪些部分?这些部分之间的关系是怎样的?哪些是互相隔离的,哪些是彼此关联的?谁依赖谁?谁应当先做,谁应当后做?每个部分的重要性是怎样的?为什么定出这样的重要性?有哪些难以理喻的需求?…… 如果你一开始就培养了这样的分析习惯和能力,以后做架构绝对会省力很多。

真正的架构师,他在设计架构之前,是可以靠计算(压力、计算能力、流量等等指标)做出很多判断的;那种动不动就喊着要“压测”的架构师,其实不是真正的架构师。

要想做软件架构,应当培养“软件与软件协作”的视角 从某种意义上讲,软件架构就是“一堆软件系统之间的互相作用”,其中的每个部分,既享受其它软件的服务,又为其它软件提供服务——请注意,这里提到的是“其它软件”,而不是“其它人”。 然而在如今的计算机教育体系中,大量的人员还是被培养为按照“上帝模式”来开发软件:一切都在我的掌控之中,我动动手指就可以天翻地覆,我要做更改或重构,强大的开发工具分分钟就可以帮我搞定;我自己设定程序的运行规则,世界按照我设定的规则来运转。如果只是开发单机软件,这种心态或许没有问题,但是要做架构师,则万万不能。

在软件系统中的修改和重构是无比麻烦的。一旦你发布了一个接口,就给整个系统添加了一条契约,就很难知道未来会有什么人、在什么情况下来调用,而且你必须持续维护这个接口,再也享受不到本地修改那种掌控一切的便利。这种时候你的每个决策都应当经过审慎的思考,如果“高内聚、低耦合”对于开发人员来说还只是应当“提倡”的设计原则,对于架构师来说就是必须保证的底线,突破这条底线,等着你的就是无数鲜血淋漓的惨案铺就的不归路。

来自《做软件架构该如何入门》

架构师要以设计师和书籍作者的标准来要求自己,即产品一旦交付,很可能改动需要花费大量的时间和成本。

绝不要使用在印刷物里经常看到的隐喻、明喻和其他修辞方法。
如果一个字能说清,不要用两个字。
但凡一个字能删掉,一定要删掉。
只要能用主动语态,绝不要用被动语态。
能用常用词的时候,不要用外来词、术语和行话。 - 绝不要用粗俗语言,为此可以打破上面任一规则。

来自《经济学人写作法》

虽然是针对英文的写作策略,但是精神放到中文里大约也是适用的。

重构绝不是简单的把代码从一个地方移到另一个地方,很多时候,有些地方可能比写代码还要需要技巧。因为是基于一些已经成熟的代码,所以一定程度上简单,因为有些细节已经实现了。但从另一个意义上来说,需要把一些功能块抽象、去重复、并重新构造。有的时候想想,有点像整理房间。那么最重要的一点,就是你知道最后整理完的理想状态是什么样,并且始终脑海里有这个构图。

重构的代码,可能还有人在做并行开发,也可能有依然未实现的设计。如何避免和别人的代码冲突,以及为后期开发留下余地,重构的时机很重要。尽量做到代码重构后不需要有大的框架改动。尽可能与同事们协调,挑选一个他们对共享部分改动最少的时候进行。

这次重构,基本上很顺利。有三个自己觉得值得分享的经验。 一、预重构:对框架进行粗略的大刀阔斧的改动,把函数和参数进行抽象和梳理,但是忽略实现的细节。加一些 TODO,说明自己还想做哪些改动。这样做一个大的 PR,并描述出自己想做的东西,发给所有工程师,看看会不会有人对改动的大纲有意见或者建议。因为粗糙,差不多一两天就能弄完。老板和同事当时给出了很多意见,这样就避免了后期做细致改动时再有意见不统一的麻烦。同时这个预重构的代码帮助自己对 “成竹” 有个很细致的把握。 二、端到端的测试例集:大军未动,粮草先行。重构未动,测试先行。因为重构会改变细节的实现,但是已有代码的 API 层的行为是不应该有变动的。重构前,确保足够的 Test Case Coverage,让端到端的 Test Case 尽可能地覆盖所有的场景。这些 Tests 在整个重构中不应该再变动。它们是保证重构没有改变系统行为,没有引入新 Bug 的护城河。 如果有可能,一些 Monitoring 和 Logging 机制也是保证行为一致性的一个重要手段。 三、定计划,化整为零:经过预重构后,大概知道自己需要有哪些改动。根据它们的 Dependency,自己做一个 List,List 里面每一步要做什么,和前后的其他改动有没有关联,怎么关联,怎么保证每一个 PR 的改动、独立进 Production 时不会对其他特性产生影响。这样,一个个小的 PR 出去,一来降低风险,二来同事们做 Code Review 也会轻松很多。

执行的过程中,三点很重要: 一、每个 PR 出去,一定和相关的工程师做好足够的交流。改别人的代码一定要保证对别人的尊重,因为所有的细节都是别人的劳动成果,他/她们也对这些代码最为熟悉。如果可能,in Person 告诉她们为什么这段你要这么改,征求他们的意见。PR 出去后,也 tag 这些人,因为他们是最好的 Reviewer。 二、每一个小改动,如果可能,改 Test 和 改 Implementation 尽可能的 Decouple。也就是说,尽量避免同时两者都改。这样一定程度上也可以保证行为一致性。虽然这个很多时候比较困难,因为重构中不可避免地会改内部函数的接口。 三、保证自己按照重构计划进行的同时,Keep 一个 Change List,包括 TODO List(便于 Keep Track 自己的进度以及保证没有漏掉什么)。另外,如果有对设计的变更,一定要保证设计文档的更新。这个一点也拖拉不得,文档一旦产生不一致,会对别的开发者(或 API 使用者)带来极大的困扰。有需要的话,重要的改动应该 Email 所有相关的人。

首先,如果重构的代码同时还在开发,尽量速战速决。时间长了就会变得复杂,因为新的代码和重构部分又开始相互影响。所以自己这一两周,倒是加班的厉害些。不过我们工作时间有弹性,需要快的时候动作快些,不忙的时候再休息好了。 另外就是重构中保证 over Communication。几乎每个改动,我都会和老大以及相关的同事再三确认,宁愿显得啰嗦些。程序的世界里,再小心也不为过。 最后,有一帮靠谱的同事真的很幸运。重构其实是一个极其需要协作的活儿。如果不是我周围的人都特别优秀,我觉得这事儿做起来可能要困难的多得多。

来自《也谈代码重构》

大型项目中的代码重构难度不亚于发布新版本,是各种技术团队都不能回避的问题。


全文主要围绕“性能,可用性,伸缩性,扩展性,安全”这五个要素 性能,可用性,伸缩性这几个要素基本都涉及到应用服务器,缓存服务器,存储服务器这几个方面
三个纬度:演化、模式、要素 五个要素: 性能,可用性,伸缩性,扩展性,安全
初始阶段的网站架构:一台服务器,上面同时拥有应用程序,数据库,文件,等所有资源。例如 LAMP 架构 应用和数据服务分离:三台服务器(硬件资源各不相同),分别是应用服务器,文件服务器和数据库服务器 使用缓存改善网站性能:分为两种,缓存在应用服务器上的本地缓存和缓存在专门的分布式缓存服务器的远程缓存 使用应用服务器集群改善网站并发处理能力:通过负载均衡调度服务器来将访问请求分发到应用服务器集群中的任何一台机器 数据库读写分离:数据库采用主从热备,应用服务器在写数据时访问主数据库,主数据库通过主从复制机制将数据更新同步到从数据库。应用服务器使用专门的数据访问模块从而对应用透明 使用反向代理和 CDN 加速网站响应:这两者基本原理都是缓存。反向代理部署在网站的中心机房,CDN 部署在网络提供商的机房 使用分布式文件系统和分布式数据库系统:数据库拆分的最后手段,更常用的是业务分库 使用 NoSQL 和搜索引擎:对可伸缩的分布式有更好的支持 业务拆分:将整个网站业务拆分成不同的应用,每个应用独立部署维护,应用之间通过超链接建立联系/消息队列进行数据分发/访问同一数据存储系统 分布式服务:公共业务提取出来独立部署
演化的价值观 大型网站架构的核心价值是随网站所需灵活应对 驱动大型网站技术发展的主要力量是网站的业务发展 误区 一味追随大公司的解决方案 为了技术而技术 企图用技术解决所有问题
模式的关键在于模式的可重复性 分层:横向切分 分割:纵向切分 分布式:分层和分割的主要目的是为了切分后的模块便于分布式部署。常用方案: 分布式应用和服务 分布式静态资源 分布式数据和存储 分布式计算 分布式配置,分布式锁,分布式文件,等等 集群:多台服务器部署相同的应用构成一个集群,通过负载均衡设备共同对外提供服务 缓存:将数据放距离计算最近的位置加快处理速度,改善性能第一手段,可以加快访问速度,减小后端负载压力。使用缓存 两个前提条件 :1.数据访问热点不均衡;2.数据某时段内有效,不会很快过期 CDN 反向代理 本地缓存 分布式缓存 异步:旨在系统解耦。异步架构是典型的消费者生产者模式,特性如下: 提高系统可用性 加快网站访问速度 消除并发访问高峰 冗余:实现高可用。数据库的冷备份和热备份 自动化:包括发布过程自动化,自动化代码管理,自动化测试,自动化安全检测,自动化部署,自动化监控,自动化报警,自动化失效转移,自动化失效恢复,自动化降级,自动化分配资源 安全:密码,手机校验码,加密,验证码,过滤,风险控制
架构是“最高层次的规划,难以改变的规定”。主要关注五个要素: 性能 可用性(Availability) 伸缩性(Scalability) 扩展性(Extensibility) 安全性
高性能 性能的测试指标主要有: 响应时间:指应用执行一个操作需要的时间 并发数:指系统能够同时处理请求的数目 吞吐量:指单位时间内系统处理的请求数量 性能计数器:描述服务器或者操作系统性能的一些数据指标 性能测试方法: 性能测试 负载测试 压力测试 稳定性测试
性能优化,根据网站分层架构,可以分为三大类: Web 前端性能优化 保护网站安全 通过配置缓存功能加速 Web 请求 实现负载均衡 减少 http 请求 使用浏览器缓存 启用压缩 CSS 放在页面最上面,JavaScript 放在页面最下面 减少 Cookie 传输 浏览器访问优化 CDN 加速:本质是一个缓存,一般缓存静态资源 反向代理 应用服务器性能优化:主要手段有 缓存、集群、异步 多线程(设计为无状态,使用局部对象,并发访问资源使用锁) 资源复用(单例,对象池) 数据结构 垃圾回收 分布式缓存(网站性能优化第一定律:优化考虑使用缓存优化性能) 异步操作(消息队列,削峰作用) 使用集群 代码优化 存储服务器性能优化 机械硬盘 vs. 固态硬盘 B+ 树 vs. LSM 树 RAID vs. HDFS
高可用 高可用的网站架构:目的是保证服务器硬件故障时服务依然可用、数据依然保存并能够被访问,主要手段数据和服务的冗余备份及失效转移 高可用的应用:显著特点是应用的无状态性 Session 复制 Session 绑定 利用 Cookie 记录 Session Session 服务器 通过负载均衡进行无状态服务的失效转移 应用服务器集群的 Session 管理 高可用的服务:无状态的服务,可使用类似负载均衡的失效转移策略,此外还有如下策略 分级管理 超时设置 异步调用 服务降级 幂等性设计 高可用的数据:主要手段是数据备份和失效转移机制 失效确认 访问转移 数据恢复 冷备:缺点是不能保证数据最终一致和数据可用性 热备:分为异步热备和同步热备 数据一致性(Consisitency) 数据可用性(Availibility) 分区耐受性(Partition Tolerance) CAP 原理 数据备份 失效转移:由以下三部分组成 高可用网站的软件质量保证 主干开发、分支发布 分支开发、主干发布 网站发布 自动化测试 预发布验证 代码控制 自动化发布 灰度发布 网站运行监控 警报系统 失效转移 自动优雅降级 用户行为日志采集(服务器端和客户端) 服务器性能监控 运行数据报告 监控数据采集 监控管理
伸缩性 大型网站的“大型”是指: 用户层面:大量用户及大量访问 功能方面:功能庞杂,产品众多 技术层面:网站需要部署大量的服务器 伸缩性的分为如下几个方面 网站架构的伸缩性设计 纵向分离(分层后分离) 横向分离(业务分割后分离) 不同功能进行物理分离实现伸缩 单一功能通过集群规模实现伸缩 应用服务器集群的伸缩性设计 轮询(Round Robin, RR) 加权轮询(Weighted Round Robin, WRR) 随机(Random) 最少链接(Least Connections) 源地址散列(Source Hashing) HTTP 重定向负载均衡 DNS 域名解析负载均衡 反向代理负载均衡(在 HTTP 协议层面,应用层负载均衡) IP 负载均衡(在内核进程完成数据分发) 数据链路层负载均衡(数据链路层修改 mac 地址,三角传输模式,LVS) 负载均衡算法 分布式缓存集群的伸缩性设计 Memcached 客户端(包括 API,路由算法,服务器列表,通信模块) Memcached 服务器集群 Memcached 分布式缓存集群的访问模型 Memcached 分布式缓存集群的伸缩性挑战 分布式缓存的一致性 Hash 算法(一致性 Hash 环,虚拟层) 数据存储服务集群的伸缩性设计 关系数据库集群的伸缩性设计 NoSQL 数据库的伸缩性设计
可扩展 系统架构设计层面的“开闭原则” 构建可扩展的网站架构 利用分布式消息队列降低耦合性 事件驱动架构(Event Driven Architecture) 分布式消息队列 利用分布式服务打造可复用的业务平台 Web Service 与企业级分布式服务 大型网站分布式服务的特点 分布式服务框架设计(Thrift, Dubbo) 可扩展的数据结构(如 ColumnFamily 设计) 利用开放平台建设网站生态圈
网站的安全架构 XSS 攻击和 SQL 注入攻击是构成网站应用攻击最主要的两种手段,此外还包括 CSRF,Session 劫持等手段。 攻击与防御 Error Code HTML 注释 文件上传 路径遍历 表单 Token 验证码 Referer Check 避免被猜到数据库表结构信息 消毒 参数绑定 SQL 注入攻击 OS 注入攻击 消毒(即对某些 html 危险字符转义) HttpOnly 反射型 持久型 XSS 攻击:跨站点脚本攻击(Cross Site Script) XSS 防御手段 注入攻击 注入防御 CSRF 攻击:跨站点请求伪造(Cross Site Request Forgery) CSRF 防御:主要手段是识别请求者身份 其他攻击和漏洞 Web 应用防火墙(ModSecurity) 网站安全漏洞扫描 信息加密技术及密钥安全管理 把密钥和算法放在一个独立的服务器上 将加解密算法放在应用系统中,密钥放在独立服务器 信息传输:公钥加密,私钥解密 数字签名:私钥加密,公钥解密 不可逆,非明文 可加盐(salt)增加安全性 输入的微小变化会导致输出完全不同 单向散列加密:不同输入长度的信息通过散列计算得到固定长度的输出 对称加密:加密和解密使用同一个密钥 非对称加密 密钥安全管理:信息安全传输是靠密钥保证的,改善手段有: 信息过滤与反垃圾 文本匹配 分类算法 黑名单

来自《大型网站技术架构 - 入门梳理》

基本来说比较全面了,如果都掌握了,可以作为核心开发者了。

个人发展

1、你必须要办事靠谱,能快速解决问题,这样才会受关注 2、在较小的职业环境中精益求精。 作为一个刚毕业的程序员,要是在写程序、数据库方面,公司里有无数人的水平都比我强,但我会的几项技能,属于非常冷门,没有人其它人会,而且能解决很大问题,给别人的印象深刻,一旦有类似的问题第一个就会想到我。

来自《如何建立自己的个人品牌并赚到钱》

所以如果有机会负责一个项目,拼尽全力也要把事情做好


一个简单的工作是,回复邮件,抄送有关人,告诉大家,你已经接受了任务,并安排了排期,如果你的任务排期有点靠后,要简单解释原因.大约什么时候可以有时间进行这个任务,大约多少时间后会给汇报。 表示已接受任务,并给出大约的汇报时间表,是一个非常重要的沟通细节,可以让管理者明确知道你的状态和安排。

那么变化出现的时候,一定要及时汇报给你的上司,以及相关可能受到影响的其他同事。 比如,有临时任务,或者线上系统出现意外故障抢修,导致计划中的任务延期,这个必须要及时汇报出去。 有些人,别人不问,自己也不讲,结果整个项目进度因此出问题,他觉得,不是我的问题啊,都是不可抗力啊。那个,确实他可以有正当的理由导致了时间表变更,但是没有通报其他人,就是非常错误的。

某个团队立项,需要其他团队的参与协助,或者,团队中来了新人担任一些重要的工作。 相关的负责人,在介绍项目和工作任务的时候,应该尽可能设身处地站在对方角度,去提供更完整的项目背景信息,以便对方加深理解和认知。 反过来说,如果你开始加入一个项目,不管是作为一个新人,还是作为一个合作团队,对这个项目背景如果不够清晰,务必要追问明确,尽可能清晰相关背景和目标。

创业公司,人力和资源紧缺几乎是必然的,导致项目中,会出现一些资源脱节,或者配合团队延误等各种情况。 相关的负责人,或者哪怕只是一个参与者,应有意识,主动去推进项目的进行,并在力所能及的情况下,主动承担导致延误的一些非自己工作职责的事情。 这个素质和工作态度,相信在任何一个积极向上的公司,都是受欢迎的。

源紧缺,人力紧缺,以及各种可能遇到的困难和障碍,都会导致项目的延误,甚至夭折。而很多时候,一些关键因素并非是高不可攀的技术和不可逾越的障碍,往往就是相关项目负责人是否还在坚持的去推动。 有时候就是这样,相关的技术人员,产品人员,永远都有一堆看上去都很重要但实际上都是在疲于应付的差事。 这时候,如果不能有一个积极推动项目进行的人,很多事情可能永远都要在等待资源的阶段,无法进行。 主动推进包括,第一,不断的询问进度,获得反馈;第二,不断寻求资源和人力支持;第三,针对当前影响进度的问题和困难发起讨论,并寻求可解决的方案或路线图。第四,在资源和人力紧缺的情况下,针对性调整计划或者任务,让项目可以规避一些障碍,继续进行。第五,不断争取人力资源,包括但不限于敦促招聘,外包,跨部门借调,乃至兼职等。

当你完成了一个项目,完成了一件工作,你汇报完,这个事情结束了么? 在很多情况下,其实并没有。举个例子,你接受安排做了一个系统优化升级的工作,或者产品优化升级的工作,然后,你完成了,也提交了,领导回复一句话,做的不错,注意持续观察。 然后,没有事故,没有故障,这事就算完成了? 其实并不是,10天,或者30天,设置一个你认为可以体现效果合理的时间区段,对升级后的系统表现或产品表现,做个认真的总结。 如果是系统优化,那么比如说,负载的情况,高峰时期的支撑情况,和优化前对比的数据,以及可能潜在的风险和下一步的优化方向。 如果是产品优化,那么比如说,用户的留存率,活跃度,各项指标,针对优化前的对比,以及可能潜在下一步的优化方向。 这个反馈和总结,就非常有意义。 从一个被动的,接受任务完成任务的员工,到主动的,可以积极反馈并给出一些产品或技术目标的员工,你的职场之路,也就宽阔起来了。

下面做个综合案例,来说明一下。 1、你参加了一个项目讨论会,并在上司要求下承接其中的一份任务。会后你收到了会议记录和任务分派邮件。 不主动的你,默默自己安排了排期和计划,并在公司的项目管理系统里提交了该任务,但只有你的上司看到了这个任务,而相关部门和其他同事并不了解你的进度和计划。 主动的你,发布回复,表明已了解该任务,并周知大家你的排期,以及可能没有优先排期的理由和原因。同时,提出需要配合或其他资源的需求。 2、任务进行中,你发现你对项目背景和一些需求的定义,不是彻底清楚明确。 不主动的你,文档怎么写我就怎么做,其他的不关我的事;不清楚的地方脑补,或者上网搜索。 主动的你,列出你所希望理解的清单,发送给相关需求的定义者或项目发起的管理者,希望对方能抽出点时间解答一下你的疑惑。 3、因为某些特殊的情况,你被调去从事紧急优先的事情,发现无法按时完成进度。 不主动的你,这个情况众所周知(很可能是你以为这样),而且显然不是你的责任,默默把排期延后就是了。 主动的你,立即周知相关人员,汇报排期延后的情况,并给出原因说明。 4、你完成了部分工作后,发现配合资源没有到位,或者配合的人没有按时完成相关工作。导致你难以往下继续。 不主动的你,这又不是你的责任,相关人员和资源又不归你管,先忙别的事吧,反正你又没偷懒,领导总说不了你啥吧。 主动的你,积极了解情况,看看能够如何调整或规避,并与相关负责人讨论是否可以在缺乏配合的情况下继续前进。 5、项目完成上线,初步表现正常,达到预期 不主动的你,该干的都干完了,做其他事情就是了。 主动的你,做其他事情同时,对项目完成效果做一定的数据跟踪,在一定时间段后,给予一个总结汇报,并整理其中的经验和教训,以及下一步可能的方向和目标。 以上,希望对进入职场的年轻人,有所帮助

来自《谈谈主动工作》

caoz 大大的文章每次都会让我非常受益,这一篇是值得好好总结的文章。


所谓“行业”,通常是就公司而言的,指的是公司业务所在的领域。比如“运输”、“零售”、“电商”等等。 所谓“职业”,通常是就个人而言的,指的是个人所从事的具体工作。比如“货车司机”、“营业员”、“平面设计”等等。

通常我们说的“向专家学习”,其实是没有明确方向的,因为专家既有行业专家,也有职业专家。假设你在一家在线商店做程序开发,那么你的行业是电子商务,职业是程序员。选择行业作为发展方向,就应当侧重了解以下问题:电商的应用有哪些特点,在系统的选型和使用上有哪些讲究,哪些问题适合使用什么框架和中间件解决…… 选择职业作为发展方向,就需要侧重了解以下问题:现有的编程语言和框架有什么功能,什么特性,系统有哪些技术指标各表示什么意思,系统大概会出什么问题应当怎么解决…… 注意上面我说的是“侧重”,极度“偏科”的组合是没有市场的。

在这种情况下,行业知识的价值更高也就不难理解了。如果有两个程序员,甲的职业技能更强,用一个月时间把仓储管理系统的响应速度提高了100%,乙的行业知识更多,用一个月时间把仓储管理系统的准确率提高了40%,出货速度提高了20%。对如今电商行业的大多数公司来说,谁的价值更高,恐怕是不言而喻的。

来自《“职业程序员”不必那么“职业”》

这篇文章的思路非常有意思,给我很大的启发,行业和职业之分,确实是值得提前考虑的问题,毕竟『两手都要抓,两手都要硬』,很多时候技术的改进再大,远不如对业务深入了解之后所做出的调整。总体来说,关键是做事情,要挑最有效率的方式来把事情做好。

实力型的活动中,刻意的训练能很有效地提高实力。 在运气型的活动中,我们要记得短期内实力的作用不大,实力再高也不会有立竿见影的反馈。

如果事情充满变数,就关注过程,尽量减少人为的失误 用少量的赌注预防意外的发生,或者投资更高风险的活动。 运气左右的活动,应该避免最优化的策略,因为最优化的策略,灵活性是最低的

当你在竞争中处于优势,你要简化比赛,以压倒性优势战胜对手。 当你在竞争中处于弱势,你要制造各种意外或开辟新的战场,将比赛复杂化。

来自《一个商业院教授给出提高运气或实力的科学建议》

这些有意思的结论其实都可以从概率中这样那样推导出来,或者哪怕是英雄联盟联赛中不同队伍的策略也能看出一二,这也是为什么人人都需要重新学一下概率,尤其是理论结合实际的概率。

安全攻防

破坏的力量,远大于善意的力量,这是世界的真相。

你做程序员,你要明白黑客常见的入侵途径和手段,并有明确的防范思路。

你做dba,你要知道彩虹库和类似cmd5.com这样巨大的在线破解库,你要知道不加salt的md5根本拦不住破解。 你做运维,你要知道缓冲区溢出是咋回事,最新的漏洞你系统有没有补,如果出现了公开的0day,是不是第一天可以知道你们在不在影响范围里,还有爱用DDoS敲诈的那帮人最常见的招数和对策是什么。 你做产品和运营设计,你要明白防范羊毛党,如果你的系统存在较多的金钱交易,或者可以具有金钱交易价值的虚拟物品交易,你系统规则任何一个漏洞都可能被人利用套利。 太多一厢情愿的创业,死于对风险的无知。

你做商业系统,譬如搜索竞价或广告联盟,你要知道欺诈点击的方法和由来,中国各行业,同行恶意竞争的残酷,我猜很多人并不真的了解。 你做游戏,嗯,你知道多少大作死于或半死于私服和外挂么。 你做推广,你买量,你要知道哪些平台是规规矩矩给你做用户,哪些平台的流量有水分,有各种见不得光的东西塞在里面,咱不说别人,我都交了多少学费了。 你创业,你要学会冷静面对各种商业诈骗,以及财务欺诈,你要当心你的财务人员中招,你辛辛苦苦搞定的企业融资一夜间被清零。(这样的案例是存在的,我就不介绍了),你还要识别不同的投资人,合作伙伴,对各种投资条款和合作协议火眼金睛。 此外,行业恶性竞争在中国是家常便饭,一夜之间你的apple store被人黑了,产品被下架,你发现是同行搞的鬼,怒不可遏申斥,人家慷慨反击,拒不承认,说你自己产品问题咎由自取,然后拉一堆大V转发,你说你哪说理去。

我们自己不做坏人,但我们要知道坏人是谁,他们在哪里,他们怎么做坏事,以及,我们应该怎样应对他们,或者,规避他们。 对我们的子女,对我们的亲人,也要不断有这样的灌输和教育,某些知名人士在网上经常爆自己行程,他觉得无所谓,但骗子会用他的行程来欺诈他的亲人和朋友。 这个世界,也并非只有黑白两色,我们会遇到很多介于二者之间的人,如果发现你软弱可欺,毫无防范,他们会变成坏人,占尽你的便宜;但如果发现你有足够的警惕性和安全意识,他们也可以是可靠的合作者和商业伙伴;在很多时候,我们往往也要学会跟这样的人合作,共事。 其实,这个问题,倒并非只是中国特色,欧洲的历史我们就知道,很多欧洲人的先辈,在有规则的场合里,可以是绅士,在没有规则的场合里,就是强盗。 很多涉世不深的年轻人,安全防范意识几乎是0,认真的说,也许他们觉得自己遇到的,大部分是好人,但请相信一个事实,一个坏人的伤害,一百个好人的抚慰也弥补不了。 单纯不是罪过,但不值得夸耀。

来自《不学点坏,怎么做好人》

确实,行走江湖,一定要注意保护自己,风险考量一开始就应该成为系统设计的一部分。

捧个钱场?