IT民工的坐井观天

前文讲了选择国外主机有哪些好处，再来看看如何选择适合自己的主机类型。

先列一下常见的主机类型：

• Share Hosting（共享主机）
• Reseller Hosting（经销商主机）
• VPS（虚拟专属服务器）
• Dedicated Server（独立服务器）
• Cloud Grid （云主机）

借用这张图片来大致说明一下这几种主机类型的区别。从很多人共享，到数人共享，直到单人完全独享。

1. Share Hosting（共享主机）

顾名思义，多人共享一台主机，你不具有操作系统的管理权限，服务商的程序提供你各种服务，一般会提供你管理界面供你部署应用等。所有用户共享CPU、内存，磁盘空间等硬件资源。通常价格是所有主机里最为便宜的，但负载能力也相对比较弱，如果网站的PV比较大的话，就很难负担了。比较常见的服务商有DreamHost, ixwebhosting, BlueHost等

图为常见的Cpanel管理界面

2. Reseller Hosting（经销商主机）

这个类似于虚拟主机，不过一般是由次级代理商进行主机的再销售，类似于合租服务器，不过对于最终用户来说还是能够拥有自己独立的管理面板，类似于上面的共享主机。这样的主机性能可能会好于共享主机，这取决于合租的人数和具体使用情况。

3. VPS（虚拟专属服务器）

VPS(Virtual Private Server)是在一台物理服务器上创建多个相互隔离的虚拟专用服务器。这些虚拟服务器以最大化的效率共享硬件、软件许可证以及管理资源。对其用户和应用 程序来讲，每一个VPS平台的运行和管理都与一台独立主机完全相 同，因为每一个VPS均可独立进行重启并拥有自己的root访问权限、用户、IP地址、内存、过程、文件、应用程序、系统函数库以及配置文件。相对于共享主机，你拥有对系统的完全管理权限，你也可以继续划分进行销售（这也就是很多极为便宜的代购由来）。

VPS作为现在较为流行的主机形式，很受中高级用户的喜欢。后面我们还会具体来介绍。比较常见的品牌有 linode, burst.net, ramhost.us, photovps等。

4. Dedicated Server（独立服务器）

独立服务器不用多说，就是在对方机房里托管着的独立服务器，你拥有100%的系统管理权限，资源。当然价格也是100%让人疼的。看你是否真的有这样的需要了。

5. Cloud Grid （云主机）

这是由亚马逊率先推出的一种新主机形式，把整个服务器网格的资源进行按单位出售，你用多少资源付多少钱，比如磁盘空间，CPU运算单元，带宽流量。目前对于国内来说，和大多数国外主机有着一样的问题，访问速度还不够理想。希望有天能够有中国的亚马逊。

就这几年的经验来看，越来越多的人开始选择国外主机来安家。有因为资费的问题，也有因为备案策略的问题。

我们来看看国外主机有哪些优势：

1. 资费比较便宜，便宜的主机一年也就3、400人民币，看似和国内的差不多，但绝大多数国外主机不限制你域名和网站的数量。从这个角度来说，价格要低于国内主机。

2. 套餐配额高，在和国内相同价格的情况下，很多国外主机提供了 无限量 的空间和网络流量。（注：请记住没有天上掉馅饼的故事，任何无限量的背后都有着这样或者那样的限制）

3. 功能更加完备，一般来说，国外主机都提供了该系统平台下能支持的流行语言平台，以及数据库，邮件服务，版本控制等。

4. 海外访问速度/无需国内备案，如果你需要面向海外用户，那选择国外主机几乎是唯一的选择，并且使用国外主机还有个好处就是无需国内的备案。相信每个搞过网站的同学都很讨厌这件事情吧。

5. SSH访问，部分国外主机提供了SSH帐号，这有什么用呢？首先你可以利用这个帐号直接在linux下进行系统操作，维护，方便了部分中高级用户。其次，也许是最大的好处，这能用来翻墙。好处不言而喻了，你懂得。

=======================

说了这些，只是为了给这个系列文章开个头，接下来让我们一点点了解其他的内容。

装了ubuntu和windows7双系统，ubuntu安装，使用grub来管理双系统启动。不过ubuntu很自然的将自己设为默认启动系统。

免不了我们调整一下双系统的启动顺序，默认是用windows7来启动。毕竟家里这台电脑其他人也要使用，默认是ubuntu不够友好。

进入ubuntu系统：

#1 :~$ sudo cp /boot/grub/grub.cfg /boot/grub/grub.cfg.bak
备份当前的grub配置文件

#2 :~$ sudo vi /boot/grub/grub.cfg

两种改法：

1) 找到 set default=”0″，把默认启动系统改成windows对应的菜单序号
2) 把windows菜单放到第一位，搜索 menuentry “Windows 7 (loader)…..，把这段移到menuentry ‘Ubuntu….之上就可以了。

为了让其他用户不会感到双系统恐惧，可以改一下菜单文字

menuentry “Windows 7 (老爸老妈，等待几秒钟，会自动进系统，不用急)…..

Git好用，但是鉴于切换起来并不是毫无代价的，还是得先体验体验。懒得去搭建自己的server了，要利用网上的资源。

对于普通用户来说，比较重要的几件事情，是否支持私有库，比如最大牌的GitHub免费账号要求项目必须开源，空间有多大，GitEnterprise看上去很诱人啊。当然剩下就是得试试看，在墙内哪个速度更合适一些。

Git最基本的认证方式是使用基于SSH的公钥认证，经常在xNix下工作的同学应该不用讲这个了吧。就单独说一下Windows怎么生成公钥（public key）。

首先是下载 Win32下的Git，推荐 msysgit http://code.google.com/p/msysgit/

然后去X:\\Documents and Settings\yourname\.ssh\ 下打开id_rsa.pub文件，里面的内容就是你的public key

为什么要从Subversion迁移到Git（一） 里提到了Subversion实践中遇到的一些问题。再来看看Git能不能针对这些问题有没有解决之道。

Git在提交对象（Commit）上有着和Subversion不一样的设计，在Subversion中每一次提交只有一个父版本，而Git的每次提交可以有多个父版本，这一不同的设计，让Git在比赛伊始就牢牢占据了主动。

来看一下最基本的分支合并过程

这是最简单的状态，trunk在c2创建了iss53分支来进行issue53相关，然后trunk和branch同时在提交更改。这里可以看到大部分提交也只是单父版本状态。

和Subversion依靠mergeinfo来做合并判别，Git要更为聪明，会寻找两个分支的共同祖先（Ancestor），来进行三方合并。再简单合并情况下，很容易的就能完成合并过程。

对于合并的版本c6，很显然这就是一个双父版本的提交版本，从简单的版本树变成了DAG(Directed acyclic graph)。这样的特性让合并的复杂度大幅降低，也让长期分支的设想有了足够的工具支持。前文提到的双向合并也不再是让人痛苦的工作了。

对比一下Subversion的合并设计吧：

图片来源：http://progit.org/book/zh/ch3-2.html

Git在合并之外还提供了一种途径，衍合（rebase），即把分支上c3的更改，把diff依次衍合进trunk。这可以很有效的消除杂乱的分支提交历史。让所有分支上的改动最终在trunk上显得是有序的。

如果你也经常为Subversion带来的手工工作感到厌倦，试试看Git，也许会省下不少时间。

参考文档：

http://progit.org/book/zh/

http://ventspace.wordpress.com/2011/03/09/understanding-subversions-problems/

http://altdevblogaday.org/2011/03/09/its-time-to-stop-using-subversion/

以前工作中主要使用CVS，SVN作为版本控制工具，使用过程中也遇到很多不尽如人意的地方。特别是在2个方面上遇到了问题：

#1 网络访问受限情况下无法在本地维护版本

#2 SVN分支合并会遇到各种问题

为了更好的折腾，开始在项目里引入Git的辅助，争取将来部分新项目迁移到Git上面去。那先来看看Subversion使用过程中遇到的问题。先看第一个问题，网络中心服务器的强依赖。

CVS|SVN为代表的集中版本控制

Git|Mercurial为代表的分布式版本控制

图片来源： http://progit.org/book/zh/ch1-1.html

因为分布式的设计，显然对网络中心服务器的依赖就消除了，当然分布式设计的初衷并不仅仅局限于此。那么第二个问题是不是能够得到很好的解决呢？我们先看一下SVN分支合并中为什么会出现各种问题。

Pre Subversion 1.5

在1.5之前，Subversion不存储任何分支（Branch）合并有关的信息，也就是说你无法知道当前分支曾经做过哪些合并。

      1   2   4     6     8
trunk o-->o-->o---->o---->o
       \
        \   3     5     7
b1       +->o---->o---->o

branch b1的HEAD是r7，trunk的HEAD是r8，当我们将b1合并回trunk后，版本树变成如下

      1   2   4     6     8   9
trunk o-->o-->o---->o---->o-->o      "the merge commit is at r9"
       \
        \   3     5     7
b1       +->o---->o---->o

trunk的HEAD变成r9，包含b1上r3-r7的更改。但是随着开发的进程，版本不断增长，版本树会变成什么样子呢？

           12        14
trunk  …-->o-------->o
                                     "Okay, so when did we merge last time?"
              13        15
b1     …----->o-------->o

这时候你是否还记得上一次合并发生在什么版本上？在一个比较大的项目中，这将是非常糟糕的局面。并且带来一个Subversion 合并（Merge）中很常见的问题，两个分支的文件比较时没有使用共同的祖先（ancestor），你是否经常被3个冲突（conflict）文件所困扰。

以上大部分内容摘自 http://stackoverflow.com/questions/2471606/how-and-or-why-is-merging-in-git-better-than-in-svn

Post Subversion 1.5

1.5开始，Subversion做出了改变，开始存储分支合并信息以解决上面提到的问题。那是不是就不再有其他问题了呢？我们来看一下现在是怎么来完成分支合并工作的。

      1   2   4     6     8   9(M)
trunk o-->o-->o---->o---->o-->o      "the merge commit is at r9"
       \      \            \
        \   3  \  5(M)      \ 7
b1       +->o---+>o--------->o

我们修改一下之前的例子，我们将trunk r4合并到分支b1，然后当分支开发完成后，我们进行Reintegrate合并，Subversion会检查svn:mergeinfo，从trunk r4开始合并分支上的改动回trunk，然后提及到r9完成Reintegrate合并。

的确这样解决了我们遇到的大部分问题。唯一已知的问题，就是一旦完成Reintegrate合并回trunk，该分支不应继续保留，如果你还需要继续保留分支，并且继续同步trunk上的改动，那就会陷入完全不可知的冲突地狱。解决方法是，删除当前分支，重新创建一个。为了尽可能的透明，你可以创建一个同名的分支。

客观的说，1.6以后的Subversion解决了90%的问题。基于上面提到的问题，SVN不建议保持长生命周期的分支（long period branch），或者称为稳定分支（stable branch）。这样整个分支管理就需要更加富有经验和技巧。

      1   2   4    11(cherry picking from b1)
trunk o-->o-->o-------->o------->o-------------------->o
          \            /         \r15                 / ? can we reintegrate ?
           \   3      /           \r16(sync merge)   /
featrue b1  +->o----->o------------>o-------------->o

考虑这样的情况，我们从trunk上创建了一个功能分支（feature branch），开发过程中发现一些改动/bug fix需要提前合并回trunk，如果我们在r11这个节点执行一次选择合并（cherry picking）回trunk，那之后如果继续像一般情况下不断同步trunk到功能分支，同时也不断把功能分支的svn:mergeinfo的起点“reset”。最终，我们在结束功能分支开发的时候，Reintegrate merge将变的不可用，并且合并的历史也会变的非常复杂。这时候就需要你对Subversion整个合并的原理非常熟悉，才能很好的去解决这个问题，否则只能带来大量的手工合并。

先有冲突，后有阿鼻。

（未完待续）

更新于：2011-06-11 @ 11:45