查看详情
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

逍遥子 曰:

得失失得 何必患得患失 舍得得舍 不妨不舍不得

 
 
 
 
 
 


我记得曾经读过俞甲子的《程序员的自我修养——链接、加载和库》,当时就觉得这个书名起的不太合适,有点不合主题,因为这本书主要讲述链接库的事情,我认为这个是编译器的一部分,是作为程序员要掌握的一项基本技能,而不修养的事情,更谈不上基本修养(但是这本书的内容依然是非常好的,我曾经仔细阅读过5遍,并且详细的做了笔记和心得,所以,我还是很认可这本书内容)。

从那个时候起,我隐约也在想一个问题:程序员的基本修养应该是什么?我觉得程序员的修养一定不是谈论技术的,他是谈论程序员这个人应该做什么事情,达到什么样的目标。直到有一天,我看到《软技能-代码之外的生存指南》,这是非常巧合的事情,京东上的图书做活动,我的免费券里面还剩下一些钱,又偶然看到它,感觉挺特别的,于是就买下来了。

作者  | 2017-6-29 8:05:46 | 阅读(212) |评论(0) | 阅读全文>>

[原]正向代理和反向代理

2016-12-19 17:58:54 阅读291 评论0 192016/12 Dec19

1.       正向代理,代理客户端发送请求,例如,我们局域网内的所有主机都不能上网,但是该局域网内有一台双网卡主机A能访问外网,这时可以在双网卡主机A

作者  | 2016-12-19 17:58:54 | 阅读(291) |评论(0) | 阅读全文>>

[原]为系统扩展而采取的一些措施——异步

2016-12-17 17:34:38 阅读275 评论0 172016/12 Dec17

1.       同步与互斥,提到异步必然要涉及到与之对应的另一个词同步

作者  | 2016-12-17 17:34:38 | 阅读(275) |评论(0) | 阅读全文>>

[原] 为系统扩展而采取的一些措施——缓存

2016-12-16 20:28:23 阅读259 评论0 162016/12 Dec16

1.       缓存

1.1        

作者  | 2016-12-16 20:28:23 | 阅读(259) |评论(0) | 阅读全文>>

[原]架构设计的立方体扩展

2016-12-15 20:31:21 阅读230 评论0 152016/12 Dec15

本文是对《架构即未来》一书第20章的总结; 
1. 立方体扩展是指X、Y、Z轴三个方向的扩展方式; 
2. X轴扩展,指水平扩展,这种方式简单易于实现,它要求服务必须是无状态的,部署1个和部署多个是一样的,这样可以根据系统当前的业务承载量来部署所需数量的服务实例,一般情况下,该业务需要与服务注册、治理、发现机制相结合,当一个服务A被水平扩展了一个新实例ai时,所依赖它(调用了它)的其他服务C需要能及时的发现这个新起来的ai,并且能把自己的对A的其他实例的调用分出来一部分到ai上,这种负载均衡机制一般有两种实现方式: 
(1) 在调用方程序中集成服务发现和负载均衡功能;如下图所示,这种方式实现负载,对调用方有影响,因为调用方在使用服务时还要集成它的服务发现和负载均衡相关功能模块。 

作者  | 2016-12-15 20:31:21 | 阅读(230) |评论(0) | 阅读全文>>

[原]构建故障隔离的架构

2016-12-15 20:15:18 阅读203 评论0 152016/12 Dec15

本文是对《架构即未来》一书第19章的总结; 
1. 什么是故障隔离的架构?个人理解,就是一个系统按照其功能划分为几个独立的子模块,子模块之间互不依赖,互不通信;这里的互不通信是指模块之间不要采用同步调用方式,可以采用中间模块转交的异步方式。 
2. 故障隔离的架构有什么好处? 
(1) 限制故障的影响范围,采用了故障隔离的架构,每个子模块的故障至影响它本身而不会波及到其他模块; 
(2) 便于故障定位和分析,相对于一个大而复杂的系统而言,小的隔离模块更简单,一旦出现故障,也更容易分析和定位; 
(3) 故障隔离是系统扩展的一种措施,我们经常采用的垂直分片理论上就是一种故障隔离方式; 
(4) 缩短

作者  | 2016-12-15 20:15:18 | 阅读(203) |评论(0) | 阅读全文>>

[原]性能测试、 障碍条件和回滚

2016-12-14 20:39:41 阅读200 评论0 142016/12 Dec14

第17章 性能测试 
1. 性能测试是指把负载和用户需求施加在系统上,以测量其相应时间和稳定性的过程,它是为了验证应用能够满足预期的性能目标;一般需要关注响应时间、吞吐量和资源利用率这三类指标; 
2. 性能测试的第一步是建立标准,没有标准的测试是没有意义的; 
3. 性能测试的环境应该与研发、QA和准生产等环境分开;之所以要把性能测试环境独立开是因为性能测试需要对整个系统施加压力,如果系统中跑着其他的程序,那么其他程序不仅影响性能测试的结果而且性能测试也可能让其他程序的工作受到影响,另外性能测试一般都需要测试很长时间,例如24小时,连续压测的7*24小时等等,隔离开的环境可以确保在测试期间都不受其他因素的影响,以确保测试结果的正确、有效性; 
4. 性能测试的环境应尽可能与生产环境一致,

作者  | 2016-12-14 20:39:41 | 阅读(200) |评论(0) | 阅读全文>>

[原]确定风险

2016-12-14 18:26:50 阅读98 评论0 142016/12 Dec14

本文是对《架构即未来》一书第16章的总结; 

1.       风险管理是提高和保持可用性及可扩展型的最基本和最重要的方面。

作者  | 2016-12-14 18:26:50 | 阅读(98) |评论(0) | 阅读全文>>

[原]聚焦核心竞争力:自建与外购

2016-12-12 20:51:06 阅读80 评论0 122016/12 Dec12

本文是对《架构即未来》一书第15章的学习与总结; 1.设计可扩展性的系统的两个关键:水平扩展和为了不可预知;水平扩展是我们服务能扩展的首要条件,未来不可预知是指在设计服务时要做好隔离,做好随时能把一个复杂组件替换掉的准备;这其实还是设计的基本功,要能从一堆复杂问题准确识别出一个组件,确定它的边界,处理好组件内和组件外的通信接口,能识别并设计好一个组件是满足不可预知条件的前提; 2.在对一个组件是自研和还是外购要以公司的成本为中心,大多数情况下,人们会误认为自己开发的要比买别人的便宜,其实不然,大多数情况下的可能结果是自己做又没做好,事情也耽误了。 3.常见的决定自建和外购的三个方法包括:(1)以成

作者  | 2016-12-12 20:51:06 | 阅读(80) |评论(0) | 阅读全文>>

[原]团队的组织形式

2016-12-9 20:35:36 阅读67 评论0 92016/12 Dec9

 

本文是对《架构即未来》第2章的总结

1.       团队组织的核心就是人员的管理问题

2.       规范和标准对于一个团队来说非常重要,个人理解,它能保障团队成果的质量底线,如果一个团队不能养成遵守规范和标准的习惯,那这个团队的产出成果就会良莠不齐;规范和标准是一个团队由游击队走向正规军的标志;

3.       团队中的任何工作都要职责清晰、明确;如果全凭自觉,靠吃大锅饭的形式,当任务下来的时候就不会有人觉得自己对它有责任,最终会造成团队像野草一样成长;

4.       团队的大小,书中给出的建议是团队的规模在6~15人;书中举了亚马逊的两个披萨的例子,即两个披萨就

作者  | 2016-12-9 20:35:36 | 阅读(67) |评论(0) | 阅读全文>>

[原]架构设计的原则

2016-12-7 20:40:14 阅读74 评论0 72016/12 Dec7

本文是对《架构即未来》一书第12章的总结;

1.      

作者  | 2016-12-7 20:40:14 | 阅读(74) |评论(0) | 阅读全文>>

[原]如何估算一个分布式系统的容量

2016-12-7 19:44:54 阅读55 评论0 72016/12 Dec7

本文是对《架构即未来》一书第11章的总结; 
1. 读完本章最大的收获是了解了应该如何评估一个系统的能力以及应该怎样为一个线上系统预留发展空间。在系统上线的时候,我们经常被问到的几个问题就是你的系统能承受多大的用户量?我们当前应该部署多少服务才能承载公司的当前和未来一段时间的业务? 
2. 文中给出若干步骤用于预估系统的预留空间,将其总结如下: 
(1)确定当前的系统负载量,包括了解系统的组成以及每个组成部分的当前负载量;我们现在一般都是采用分布式的

作者  | 2016-12-7 19:44:54 | 阅读(55) |评论(0) | 阅读全文>>

[原]生产环境的变更管理

2016-12-6 20:09:10 阅读64 评论0 62016/12 Dec6

本文是对《架构即未来》第10章的总结; 1. 变更包含广阔的范围,它不仅包括软件的升级还包括对当前环境的任何软、硬件改动,包括配置、操作系统、数据库、防火墙、网络设备等等,对于研发来说,变更最主要的还是版本升级; 2. 生产环境的变更是事故发生的主要原因,经验指出,生产环境中的事故,有很大一部分是由于软、硬件的变更而引起;这也与我们的实际工作场景相似,我们在实际工作中,一旦遇到生产环境的问题,首先要问的就是最近有没有谁对系统做过任何改动?例如版本升级、配置更改、数据库修改、网络修改等等;

作者  | 2016-12-6 20:09:10 | 阅读(64) |评论(0) | 阅读全文>>

[原]管理故障和问题

2016-12-5 19:52:34 阅读55 评论0 52016/12 Dec5

本文是对《架构即未来》第8、9章的总结。
1. 书中的的问题翻译为根源更合适。 
2. 故障是指造成服务异常的事件,包括停止服务、服务效率降低等;根源是导致故障的原因;同一个根源可能导致多种不同的故障;
3. 解决故障属于紧急事情,找到根源属于重要事情,在时间管理的四象限法制中,紧急事情优先级要高于重要事情;在实际工作中也基本如此:一旦运维发现线上服务出现问题,首先想做的事情就是尽快恢复服务,尽量减少对线上用户的影响;但是这样做有可能会把故障产生的一些现象给擦除掉,从而给分析故障根源带来更大的困难。

作者  | 2016-12-5 19:52:34 | 阅读(55) |评论(0) | 阅读全文>>

[原]流程在团队管理中的作用

2016-12-2 19:48:31 阅读63 评论0 22016/12 Dec2

1. 个人认为书中的过程改为流程更为合适;

2. 流程是什么?

个人理解:为解决特定问题而形成的套路似的解决办法,只要大家遇到这样的问题,按照流程中的步骤一步步执行,就能确保问题解决。

3. 流程能帮助我们做哪些事情?

de >个人理解:**(1)规范每个人的操作行为,让问题的解决更为规范、可控;**其实每个人都有自己的主管思维和理解,每个人看问题的角度可能都不一样,他们所形成的解决问题的办法也是千差万别的,每种方法的可行性、可靠性都不一样,因此,我们需要一套规范来约束大家;例如:我们团队的版本提测发布流程的制定,团队刚成立时大家都按照自己的思路去提交代码、送测、上线,结果在项目第一次上线时出了非常多的低级问题,例如运维要求的文档、报告未提供,版本的命名方式也不一样,给我们带来了非常大的麻烦,

作者  | 2016-12-2 19:48:31 | 阅读(63) |评论(0) | 阅读全文>>

查看所有日志>>

 
 
 
 
 
 我要留言
 
 
 
留言列表加载中...
 
 
 
 
 
 
 
 

陕西省 西安市

 发消息  写留言

 
博客等级加载中...
今日访问加载中...
总访问量加载中...
最后登录加载中...
 
 
 
 
 
 
 
心情随笔列表加载中...
 
 
 
 
 
 
 
模块内容加载中...
 
 
 
 
 
 
 
列表加载中...
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2018

注册 登录  
 加关注