Hegel2011的博客

读书 - 工作 - 生活 - 笔记

为你自己学Git笔记

从Rails把代码库迁至GitHub起,接触Git已经很长时间了。但限于svn的惯性思维,其实我始终没有真的理解Git。 毕竟,上班一直是用的svn,去年12月后才开始迁移到git,而之前一个人用用GitHub的话,也确实是当一个svn在使用,主要就是实现通过中心节点实现多个终端的内容和代码共享。

没有真正弄懂git的另一个原因,则是没有好的简明的说明教材,毕竟只是一个scm工具,自己舍不得在这上面花太多时间也是事实。而高见龙的这本《为你自己学Git》,目前只有繁体版,则写的够简洁也够深入,并且配合了很多例子,让人对git的原理、应用场景、使用方法都可以做到很清楚。

git基本操作

从Git设计之初来讲,它是去中心化的。所以本书的大部分运行环境和讲解例子都是基于本地目录。 git存储结构

git add index.html只是把文件从工作目录加入到了暂存区(staging area),git commit才能把内容放到存储库(repository)中。

不想让git管控可以给git rm加上--cached参数。 git rm welcome.html --cached,在git目录里的状态就从tracked变成Untracked

git commit --amend 可以修改最近的一次commit的内容和备注。如果要修改其他更久远的,则可以git rebase, git reset,极端情况删除.git目录重来。
同时, --amend还能往前一次commit中加入新文件。

.keep往往用于新增目录时,为了目录进入仓库而作的占位文件。

.gitignore搭配git clean -fX可清除已经被忽略的档案。

git log增加-p参数可打印输出文件的变化内容。

git blame index.html 可以看见每行是谁写的。

1
2
3
4
5
6
7
8
9
10
11
86145428 (swachian 2018-02-20 21:05:05 +0800  1) ---
86145428 (swachian 2018-02-20 21:05:05 +0800  2) layout: post
86145428 (swachian 2018-02-20 21:05:05 +0800  3) title: "Peopleware读书笔记"
86145428 (swachian 2018-02-20 21:05:05 +0800  4) date: 2018-02-16 14:20
86145428 (swachian 2018-02-20 21:05:05 +0800  5) comments: true
86145428 (swachian 2018-02-20 21:05:05 +0800  6) categories:
86145428 (swachian 2018-02-20 21:05:05 +0800  7) - 管理
86145428 (swachian 2018-02-20 21:05:05 +0800  8) ---
86145428 (swachian 2018-02-20 21:05:05 +0800  9)
86145428 (swachian 2018-02-20 21:05:05 +0800 10) 读完软件随想录,自然而然被吸引
去了另一本这个领域的名著《人件》

git checkout index.html可以把误删除的文件恢复出来,如果有多个文件可以使用git checkout .一下子切出。
上面是从staging区域切出到工作目录,如果使用git checkout HEAD~2 welcome.html则是把上两个版本的文件切出到working目录和staging目录。

checkout主要是动staging和working 区域,git reset 则会涉及版本库区域:

1
2
3
4
5
git reset master^
git reset HEAD^
git reset 85e7e30
git reset e12d8ef^
git reset HEAD~5

^的作用是表示“前一次”。

git reset 可配合模式使用,--mixed,--soft, --hard,默认是--mixed,它们对staging和working区域的反应是不一样的。因为reset的本意只是重新设置HEAD指向,顺便解决了staging和working的内容。

  • soft: 只改HEAD指向,其他都不改
  • mixed: 只动staging的内容
  • hard: 改HEAD指向,改staging,改working

git reflog 可以调出每次HEAD移动的记录日志,找回相应的commit标识。命令等于git log -g,加上-g参数也有类似效果。

HEAD指向的是某个分支,内容是具体文件ref: refs/heads/master,而这个文件里的内容则是某个commit形成的hash: ef5dcf2ab28d2ec47252703815ab97bd4108f937

git add -p index.html 可以选择编辑要加入暂存区的行。

git本地分支操作

设置分支最大的目的是保证主干不受影响。

git branch cat 增加分支,git branch -m cat dog分支改名, git branch -d cat删除分支,git checkout cat切换分支, git checkout -b cat增加并切换分支,git merge dog合并分支

Fast Forward在一个分支相对于另一个分支只有新增的commit内容时可以使用, 这是没有小耳朵的。 否则,git会再造一个commit来合并两个分支,并把一个分支向前推到新增的这个commit。 commit信息里面,Parents字段中被合并的分支名位于后面。 commit合并信息
使用--no-ff可以强制产生小耳朵的效果:git merge cat --no-ff
分支只是一個指向某個 Commit 的指標。

git rebase dog是重新嫁接分支,原理是将当前分支的全部提交一个一个提取出来, 重新计算后作为新的提交加到基准分支dog当前commit的后面,最后把当前分支的Head 指向重新apply的最新提交。所以rebase之后,之前分支commit的日期就延后了。

要回退rebase,可以使用git reflog找到rebase前的最新的commit号。
简化版本是git reset ORIG_HEAD --hard,使用ORIG_HEAD指针。

有冲突的话,先编辑,然后git add加回暂存区,再commit
如果是rebase的,则git rebase --continue

二进制的内容: git checkout --ours cute_animal.jpg, git checkout --theirs cute_animal.jpg

git rebase -i bb0c9c2 可以整理提交历史, squash: 合并commit

revertreset的作用基本相同,但revert是再增加一个commit来实现取消前一次提交的效果, 一般用于多人合作时取消某些提交。

git tag,善用tag,标签和分支最大的区别是标签打好之后这个指针不会再变化,分支则会继续前进

git stash,配合git stash list, git stash pop/apply使用, 存放手头工作,也可以先commitreset .

要从.git中完全删除文件有很多步骤要做,要先解除,在gc,最后才能删除掉。当然,不如直接删除.git算了。

产生detached HEAD的原因:

  1. 使用checkout到了一个没有分支指向的commit
  2. rebase过程中,其实都是处于detached HEAD状态,所以一旦rebase有coflct,分支状态必然不对
  3. 切换到某个远端分支的时候

git branch tiger b6d204e && git checkout tiger 该命令可以把当前的commit纳入到一个分支中,从而摆脱断头分支的状态

git远端分支

GitHub是最有名的远端版本库,可以用git clone获得远端repo库。

upstream意在设置上游分支,也就是下面这个命令中-u选项的作用。 git push -u origin master,会把origin/master设置为本地master分支的upstream。然后就 不必每次git push origin master, 直接使用git push即可。
-u = --set-upstream

git push origin master:cat 会把本地的master分支推向远端的cat分支。
git push origin :cat 可以删除远端的cat分支

git pull = git fetch + git merge, fetch同步了origin/master中的内容, 而此时orgin/master比本地master领先,那意味着原本是一个分支分出去的且京都更新,其实就是merge了, 有时候甚至还是Fast Forward方式进行,有时候可能会再造一个commit以完成任务。
但是,pull也可以是rebase方式的,例如git pull --rebase, 这就是用rebase替换上个等式右面的merge
如果push有问题,则只能先拉再推

Pull Request(PR)

简而言之,把项目fork到自己的帐号即建立一个新的远端仓库,然后修改先push到这个新仓库, 然后比对自己和origin库的异同拉出一系列commit集合,这个集合就是Pull Request。 意思是请求原作者拉回去(Pull)的请求(Request)。 原作的叫base fork,自己的叫head fork

公司内部PR的用法:每个人fork到自己的帐号下,待完成后PR回公司的项目。负责管理这个项目的人受到PR后, 进行Code Review并确认这个提交无误后进行合并,从而保证这个分支处于随时可上线的状态。

git format-patch fd7cd38..6e6ed76 会产生补丁文件。git am /tmp/patches/* 则是更新补丁

Git Flow

git的工作流。主要定义了5中分支组织的方式。

Effective Java 3rd Edition

「Effective Java」第三版在过年期间出版了,对比第二版主要补充了lambdastream的内容,序列化方面 则希望大家不要再使用java原生的内容,其他变化不大。但是,和第一版比较起来,变化就很大了。除上述内容外, 第二版较第一版增加了autoboxing/autounboxingenum, annotation,generic programming, 整个的编程建议也从57条增长到78条再到第三版的90条。

借用作者在第三版的前言,在1997年,Java的创始者Gosling描述java是一种“蓝领语言”(blue collar language),意味着当时的java相当简单(pretty simple)。与此同时,C++的创始人Stroustrup则警告所谓java的简单和其他很多新语言一样,只是误解以及功能上的不完善,随着时间的流逝,Java在尺寸和复杂性上都将大规模成长。不得不说,三者都是大师,而Java虽然依旧还是工业级的语言,但复杂度和规模已经较我十几年前初学时多了许多。或许,也因此大学里正在寻求一门其他语言来取代Java的教学地位吧。

此书非常经典,虽然作者说不用从头到尾通读,但是,建议还是全部都读一遍,甚至可能需要反复阅读并加以实践。比如其中的primitives和boxed primitives,即intInteger,其间的坑在新项目中就踩过,而之前阅读后只是尽量不去用Integer这些boxed的类型,而这个新项目中由于前后交互的需要必须使用了Integer,于是就把==, 内容为null的坑都踩到了。

开卷有益,何况经典!

Peopleware读书笔记

读完软件随想录,自然而然被吸引去了另一本这个领域的名著《人件》

质量

只有愿为质量倾其所有的人,质量才是免费的。一个组织如果为了质量一毛不拔,那么收获的质量也将一文不值。 制造者本身对质量会有更高的要求,良心循环下更高的质量会有更高的产出,但如果组织不愿意为此付出代价,比如高工资、项目延期等,那么就得不到这种质量

帕金森定律

工作会自动膨胀并占满一个人所有的工作时间。进度压力是一种惩罚,不能滥用。

苦杏素

李彦宏眼中的AI,就指望这个翻本了。

读到后面感觉有点泛泛而谈,只是本书确实强调工作环境要好,要相信people,减少鼓励,减少加班等等,Joel的思想确实来源于此。

Joel 谈软件- 软件随想录

《Joel谈软件》,我一直是这么称呼《软件随想录》的。 倒是才注意到,原来黑客与画家、软件随想录都是阮一峰老师翻译的,而且翻译的真不错。与此同时,阮老师也很好地推销了一下自己。本书与《我编程我快乐》不同,是很有深度的书,所以决定边读边记笔记。尤其要说一句,阮老师的注解是很显功力的。

在2004年之前,Joel的网站文集就被按blook集合由Apress出版,而阮老师翻译的是集成了2004年之后发布的文章,英文名称《More Joel on Software》。但国内的出版顺序则是先引入了阮老师翻译的《More》,后来又有另一个译者翻译了04年的那本书作为了卷1. 所以,在中国很长时间只有《More》而没有第一本。考虑到时效性以及译者的知名度,04-09这本更值得关注就是必然的了。下面的笔记是两本合计的版本,并未区分来自哪里,毕竟原作者是一个人,所以基本是一脉相承。

人员管理

第一次Bill Gates 审查

微软程序经理(Program Manager):技术水平是程序员队伍里最高级别,能做最多且最难的工作,有人格魅力,程序员队伍中最聪明的那个家伙。

比尔盖茨通过不断问问题来确认对方是否有实现任务的把握。

怎么寻找优秀的程序员

  1. 优秀的程序员很少找工作
  2. 简历投的多的大部分是不怎么样的程序员
  3. 从应届生中招募是个发现美材的办法

从工作环境开始招募程序员

  1. 私人办公室:作者的公司在纽约,但程序员都有独立办公室,当然,这个在国外也是凤毛麟角
  2. Aeron出品的名牌电脑椅
  3. 大显示器
  4. 好的办公环境和园区
  5. 同事要好,管理层要有程序员出身的人,物以类聚
  6. 像代码一样公正、有序,严格的能者上庸者下的地方,对的就能赢得任何争论的地方
  7. 有趣的活,或者简单的或者流行的活
  8. 一定自由地使用新技术
  9. 编程框架体现美、幸福和激励

三种管理方法

团队、公司、军队、国家,问题:“使得人们去做你要他们做的事”,或者说如何使得所有人都向同一个方向前进。

军事化管理法

每个人做的事情都不同的情况下,军事化管理方法很难奏效,因为没有那么多经理实现微观管理。但对军队则是必须的。

经济利益驱动法

经济驱动把内部激励变成了外部激励。内部激励是发自内心想做好这件事情,内部激励通常比外部激励强。

经济驱动也容易陷入kpi骗局,鼓励大家和制度博弈。不能把铜板丢给鸡,让鸡自己去买吃的。创造一种制度的时候,不能放弃自己的职责。

认同法

一起干活的人要一起吃饭。团建,以及营造一致的目标,爱上这个城市和工作内容。第二部分是提供必要的信息,让下属感觉被尊重。

结论:hybrid根据时间和对象灵活运用各种方式。

面人指南

千万不要雇“可能”合适的人,招人标准:1,聪明 2,能干

测试人员

测试人员独立性的必要性

大学生技术学习建议

大学只教java的危害

危害主要是两点:1. 基础知识不够扎实 2.会有很多不达标的人浑水摸鱼通过,导致招聘困难。   但是,国内国外都这样。

耶鲁大学的演讲

技术派(the geek)和务实派(the suit,穿西装的)   消灭bug的边际报酬是递减的,即随着错误越来越少,解决bug带来的收益也在变少,务实派的理论

程序本身包含多少香农熵规格说明书也要包含同样的数量

作者在微软纽约的咨询部门做过一段时间的客户顾问

做外包软件开发不好之处:1.无法用正确的方法做事 2. 做不出优秀的产品,因为都是乙方外包,能用就行。

管理只是一种不得不做、让人讨厌的杂物活,之所以公司需要管理,只是为了不影响聪明人工作,真正的天才才能做出优秀的成果。

作者在大学里学会了写作,学会了从动态逻辑课里不要读研究生,进入了Unix这座宏伟的教堂,但其实作者也从微软身上获益良多,变得足够聪明,但还是没有学到怎么开发软件。

给计算机系的建议

  1. 写作
  2. C语言
  3. 微观经济学:供给和需求,竞争优势,净现值(NPV),贴现,边际效用
  4. GPA反应4年的总体表现

设计的作用

艺术性和实用性 form follow function

进入最后测试阶段就会变得特别挑剔

你之所以会有好运气,那是因为你寸土必争

设计不用太宏伟,但细节要跟上

太多的选择会损坏内心的幸福感

作者以自己软件论坛作为例子,说明了功能和倾向性方面取舍。

大型的项目管理

微软ie8.0的开发,雷克萨斯pk橄榄树,要不要向过去兼容的问题

标准也会引发误解、困惑甚至争议

一半是理想主义,一半是实用主义

项目管理其实就是做抉择

日程安排经验的主要依据是历史数据,但相应原则如下,不过这个前提是招的都是有能力和自我驱动程序员:

  1. 只有一线程序员才能提出完成日期的估计值,管理层制定的通常效果不好
  2. 发现错误就更新原来的计划
  3. 防止管理层向程序员施压,这样的产量至多提高10%,但埋下的隐患不少
  4. 一份日程规划就是一个装备积木的盒子,要么删功能要么拖延

优秀的项目经理会让开发者觉得所有重要的设计工作都是开发者在做,而项目经理只负责打打酱油,和一些非常官僚主义的事情周旋,比如应付客户写写规范。

软件开发-冰山之谜,你能看见的永远只是实现的一部分,如同冰山露出水面的部分,而水底的部分可能还有90%

每日编译发展到现在就是持续集成

排计划

  1. 使用excel,不要用project,后者是为建造办公楼设计的  
  2. 保持简单,7列:feature、task、优先级、预估、现在预估、已流逝、剩余工时,最终完成时剩余工时==0,现在预估==已流逝
  3. 每个功能点要分解任务列表  
  4. 只有负责些代码的程序员才能预估时间
  5. 细分任务到小时单位,作者理解的设计就是决定要做什么  
  6. 记录原始和当前的时间估计,实现不断练习估算时间  
  7. 每天更新消耗时间栏  
  8. 考虑假期  
  9. 考虑调试代码的时间,考虑修复bug的时间  
  10. 考虑集成时间,就是几个人的工作拼接起来  
  11. 预留缓冲时间:第一预估可能有延时,第二可能有新任务,第三可能有冰山  
  12. 永远不要让开发经理压缩程序员预估的开发时间  
  13. 计划就像积木:通过强迫做减法(挑出不要的积木),你将开发出更强、更好、功能配比更优秀的产品,避免延期避免交付了还有很多鸡肋的功能  

软件世界的分类(5类)

作者把基于网络的web应用列为盒装软件,咨询软件(SAP德勤)这样的介于盒装和内部软件之间。
如果只有一个企业使用其实就是内部软件,由于边际成本的原因,内部软件通常不用质量很好。
嵌入式软件
游戏和嵌入式软件一样,对软件的质量要求高,因为一般来讲游戏和嵌入式软件很少升级,也很少会出2.0版。即往往只有一个版本。
临时性软件,比如一段脚本。

编程建议

应用型匈牙利命名法 vs 系统型匈牙利命名法,后者臭名昭著,前者其实意图是表明变量的用途而不是type。

开软件公司

做生意就像看植物增长,是一种乐趣

如果你想压低程序员的工资,那么你就会得到质量很垃圾的软件,而这实际上也不会为你省下很多的钱。举了耶鲁大学的例子说明程序员的生产率差距有5-10倍。

此外,生产率不同的同事而是“普通”程序员根本做不到优秀程序员所做的事情,“飙不出高音”

Seinfeld中Soup Nazi一集很看好

作者的程序员价值论断是针对生产最终产品的公司,如果只是为了内部使用,配合运营而不是销售,那么只要够用就行了,不需要特别优秀

Jonathan Ive, 苹果的设计师

办公室的租金成本是2004年人均700美金/月,人均建筑面积40平米,所以每个人有自己的办公室,目的就是招募到优秀的程序员

对你最重要最关键的部分,你一定要使用更原始的工具

客服不外包有利于永久性地解决问题

面向整个市场的软件(产品)和定制化软件

一家软件公司要想成功,必须要有一名程序员执掌大权

只有招聪明的人,才能充分授权。

“麦当劳的”厨师 pk 真正的大厨,军事化标准化的流程只能产出麦当劳,大厨都是随意的。

NIH(Nothing in Here)对于关键部分,要坚持自己的研发

慢慢发展和烧钱发展的适用场合

兼容性是先有鸡还是先有蛋问题的一大解法

用户粘度和离开的门槛是要在你占据优势地位之后的,在此之前,最好的办法是降低用户使用门槛。

开源软件的策略:是使得硬件标准化、商品化,02年就列举了sun公司的错误

FUD战术,就是欺骗和恐吓的意思了。所谓雾件,就是对各种功能特性和产品作出口头许诺。但实际上根本拿不出可以卖的东西。把微软黑的厉害。 因为含糊其辞,大家会产生微软与自己的观点不谋而合的错觉。

.net缺少链接器(linker)。把编译后版本和程序中所有函数库的编译后版本合并起来,然后剔除掉所有不需要的库函数,生成一个二进制文件。

发新股不分红是为了让报表的利润好看

以最终用户为主和以程序员为主构成了windows和unix两类不同的文化,然而实际上以最终用户为主的文化来源于Apple

关于规格说明书

规格说明书体现的是写作能力,他的规格说明书写的让人很容易阅读。

待解决的问题需要在说明书里确定,不要觉得可以先让程序员做简单的部分,之后再慢慢思考并解决剩下的难题,这不是好主意,因为在实现代码的过程中会冒出许多新问题。

项目经理/产品经理没有权利让程序员听命,必须努力争取大家的认同才行,这种方式才能确保团队永远在做正确的事情。

规格说明书古今中外其实都不太有人爱读,因此写好很难。所以要写出引人入胜的规格书可以遵循一下几点:

  1. 要幽默  
  2. 像编写用大脑执行的代码一样写规格书,仅仅做到正确不够还要易于理解  
  3. 写的尽可能简单, 并擅用排版  
  4. 重读并修改几遍  
  5. 尽量不要套用模板

我编程我快乐

在图灵买了本《我编程我快乐》的电子书。其实原版名字就是著名的《My job went to India》的第二版, 原书名的意思也是如何成为一个卓越的程序员。

由于作者出身rails背景,所以大部分的思维我之前已经了解,真的大有收获的东西并不多。摘要一下有以下几点:

市场

  1. 技术是有时间差的,在成熟或者说供需平衡间可以赚到相对多的价钱。
  2. 不要担心做团队中最差的,反而要追求这种和高手过招的机会,这样才能走出舒适区。
  3. 不要听从父母的,即使西方也是一样的。父母只是希望你平安,但大部分父母的境界注定无法帮助你卓越。
  4. 热爱你做的事情和市场。

产品

  1. 了解行业如何运转
  2. 跟踪技术的原理
  3. 寻找良师益友,自己也要做良师

执行

  1. 8小时激情燃烧
  2. 公司离开哪个员工都照样转
  3. 说“不”

推销

  1. 推销包含了一定的迎合
  2. 感觉是最重要,脑力劳动的评价主要靠感觉
  3. 建立关系混圈子

保持技术领先

  1. 研究尖端技术
  2. 没有终点
  3. 留意市场变化,主要跟踪技术达人

实用软件需求

Kovitz的这本书大概是七八年前看DHH的博客时得知的,发现有中文版就买了回来。但一直没有读完。原因在于本书还是按比较正统的方法讲解如何写好明确的软件需求与规格。按作者的理解,软件开发细化的模式有二:

一. 所有内容都是渐进式细化的,先原型然后几轮迭代后深入到细节; 二. 每个开始的需求数量很少,但都很到位,每轮迭代就是新增几个需求并实现。

而在我大部分的工作都是采用的策略一,所以这本书对我的吸引力就不大。毕竟在老单位分工没有那么细,沟通相对简单,并不需要那么细节丰富的需求文档。但是,新单位就都不一样了。

现在的单位是一个公司人数不多,但规模建制很丰富的公司,即使我个人带的团队也大了许多,需求不单是项目负责人和客户之间沟通的东西,同时也是产品、ue、ui和研发、测试之间沟通甚至绝对对错的基础。这种情况下,如何书写需求(其实是要求产品如何书写),就变得相当重要了。

Kovitz 这本书的精华是第九第十章,讲的是如何描述领域中的集合(模型)和类之间的关系,以及这些模型对应的事件和发生序列。

集合包含两种类型:

  1. 实体类,或类。比如发票、客户
  2. 实体类之间的关系。(客户1, 发票1),(客户1,发票2)。。。,关系其实是类的集合

每个实体类要文档化的信息:
1. 实体类的基本信息说明;
2. 属性值列表,包括属性的定义,可能值的集合(取值范围、类型或者枚举集合)和含义
3. 存在的标识成员的属性(主键)
4. 与该类有关的实体类,这个主要用文字描述为主、画类图为辅,要在描述中说清楚一堆多,多对一的关系
5. 影响成员的每个事件,以及影响那些属性和关系。

基数是指多对一的配套关系。连线的秘密是这样的: * 竖线表示1 * 圈表示0 * 三条线表示乌鸦脚,没有合并 * 基数最靠近两端的表示最大值,次近两端的是最小值

微服务笔记

微服务是Martin Fowler定义的一个术语,出自 https://martinfowler.com/articles/microservices.html

是伴随着敏捷开发和云服务部署流行而兴起的一种架构。微服务架构风格[1]是一种将一个单一应用程序开发为一组小型服务的方法,每个服务运行在自己的进程中,服务间通信采用轻量级通信机制(通常用HTTP资源API)。这些服务围绕业务能力构建并且可通过全自动部署机制独立部署。这些服务共用一个最小型的集中式的管理,服务可用不同的语言开发,使用不同的数据存储技术。

具备的特征包括:

  • 水平扩展服务能力时,可以扩展只需要扩展的模块而不是全部
  • 组件多以服务的形式提供
  • 团队多按业务能力/功能组建
  • 团队始终围着产品,而不是做完了就丢给运维
  • smart endpoints and dumb pipes,其实就是管道扁平化,针对SOA中部分总线太过只能而言
  • 去中心化的管理,微服务意味着可以自治化,而不是谈标准化
  • 可以多个编程语言同时使用,只要保持彼此间通信简单(http+lightweight messaging)
  • 数据存储也是去中心化的,Polyglot Persistence,存储/数据库也是每个服务自己定
  • 基础设施自动化程度高,实现持续提交和持续集成
  • 开发者和用户间会更容易建立更多的联系,要持续关注软件如何帮助用户提升业务能力,而不是把软件看成是将要完成的一组功能
  • 针对失效的设计,使用服务作为组件的一个结果是,应用程序需要被设计成能够容忍服务失效,如断路器模式

Spring Cloud 服务治理

服务治理是近年来架构中的热点部分,尽管比照ICE这些内容其实十几年前就已经有了, 只是五六年前伴随着系统越做越庞大,才变得必要起来。

简单理解一下,其主要内容基本是:

  • 要有一个服务中心,服务中心最好是集群的
  • 要能向中心注册服务,服务的地址用名称而不是ip硬绑
  • 要能发现一个服务,其实就是用名称通过服务中心找到服务的ip和端口
  • 要一个可以轮流访问服务集群的客户端
  • 此外再配合上消息总线等内容

有了这些,基本一个服务治理的框架就基本形成了。

《Spring Cloud 微服务实战》是一本很不错的书,有动手的介绍,有源码的分析,写的也算精炼。

Eureka 服务治理中心

启动服务中心后,配置客户端主要包含两部分:

  • 服务注册相关信息: 包括服务中心地址、服务获取间隔时间、可用区域,以eureka.client为前缀
  • 服务实例相关的配置信息: 包括实例的名称、IP地址、端口号、健康检查路径等,以eureka.instance为前缀

Ribbon

Spring Cloud的负载均衡是在客户端实现的。 WeightedResponseTimeRule是个比较复杂的实现。

Hystrix

这是一个容错断路器,当出现超时等状况时直接调用指定的回掉函数。使用了RxJava库的异步操作模式, 实现了发送+观察的效果,所以可以中断请求。

Feign

在RestTemplate上进一步抽象,实现和Spring MVC对等的method封装。因为要组client,所以@RequestParam 中的value不能少。

1
2
3
4
5
6
7
8
@FeignClient("Hello-Service")
public interface HelloService {
  @RequestMapping(value="/hello1", method=RequestMethod.GET) //指明要访问的路径和方法
  User hello(@RequestParam("name") String name, @RequestHeader("age") Integer age); //指明构造请求是的参数名称
}

//调用方式
helloService.hello("DiDi", 30);

Zuul Api 网关

网关的事情就两条:
1. 路由 2. 过滤

Zuul的路由结合了治理服务,下面就把一个路径全部转发去了一个服务

1
2
zuul.routes.service-a.path=/aaa/**
zuul.routes.service-a.serviceId=Hello-Service

过滤器则可以通过继承一个抽象类ZuulFilter并实现4个方法来实现。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
public class AccessFilter extends ZuulFilter {
  ....
}

@EnableZuulProxy
@SpringCloudApplication
public class Application {
  public static void main(String[] args) {
    new SpringApplicationBuilder(Application.class).web(true).run(args);
  }

  @Bean
  public AccessFilter accessFilter() {
    return new AccessFilter();
  }
}

Spring Cloud Config

基于git(也可以是svn或本地目录)的配置中心,其实就是一个可以保存各种配置信息,然后由其他微服务读取后拉起应用。

Bus 和 Stream 消息总线和消息流

目前只支持RabbitMQ和kafka两种队列,kafka更多的好像和实时日志处理流相关

新的挑战

去新公司已经快半年了,大约一个半月前副总找谈话,打算提拔我当部门经理,负责起部门的管理工作。 并且,跟我讲了他的经历。他原本也一直不想做管理,主要顾忌有两点:
1. 怕自己干不好; 2. 怕自己荒废。直到老板请他出山帮忙,也就不得不开始从事管理工作。
副总这番话还是挺让我有共鸣的,因为对我而言,所顾忌的也是类似的情况。但既然副总和其他领导举荐我,那也不好推辞,只能赶鸭子上架尽量干了。

但一方面接了下来,另一方面却又很忐忑。因为这个部门从原先的项目组升级而来,而之前我作为架构师是配合项目组经理工作的,我当部门主管之后,和原先的经理之间存在一个换位的过程。而我们合作的四个月其实配合的还不错,尽管我感觉加班多了些,其他方面大家还都能顺畅沟通。
难点之二,本司的产品很强势,往往会有莫名其妙的需求和时间安排,而研发的地位则属于较低并且相当被动,这都不太像如今的技术性公司了,但确实是我司的现状。做架构师的时候,还可以不直接面对强势的产品和大姐头,而做部门主管则必须为兄弟姐妹们争取合理的工作安排。
难点之三,下属以农村娃娃居多,吃苦耐劳者多之,聪明干活的则很稀少,这样的团队带起来管理难度还好,但干活水平不容易高。
难点之四,真的对我能不能买账也只有天晓得,尤其是在产品如此强势的情况下,并不是每个下属都觉得应该跟着我干的。

但是,当大姐头明确地告诉我部门连我在内已经有18个人的时候,我还是挺震惊的,打那一刻起我突然对这个工作有了兴趣。

然而,毕竟没管过那么大的团队,所以要学习的地方还有很多。就我个人的特点而言,至少具备了分析问题和解决问题的基本能力, 所以满足当好一个管理者的基本条件,但必须承认在一些管理者的日常方面做的并不好。解法也只有看书、看别人的经验加自己的实践了。

看书

  1. 《轻流程:IT团队的积分式绩效管理》,蔡为东,开始学习的第一本,虽然基本的道理很对,但这套积分制度实施起来还是有点难。
  2. 《行之有效:IT技术团队管理之道》,蔡为东,此书较前一本稍早出版,相当管用,可以直接使用的办法很多,最典型的如明确了研发部门的管理讲到底就是管人和项目,团队的日常管理就是谈话、考勤、请假、报销,比较好的一本书。
  3. 《从技术走向管理—李元芳履职记》,王树文,小说形式的IT管理书籍,基本上就是把前面一本管理理论书籍用小说形式 举例了一遍。
  4. 《技术管理之巅》,一号店的经历,写的比较泛。
  5. 《软件开发本质论》,Ron Jeffries,王凌云,基于敏捷模式的软件开发论,很薄但观点很犀利,对于 尽早测试的原因讲解的很清楚,这本书对我而言最大的触动是下了要大量编写自动化测试案例的决心。只有快速地 验证软件是不是正确,才不至于把问题留到最后。