2009 六月一个程序猿孙小一,孙小二,PHP,MYSQL,LINUX,APACHE,原创技术,扯淡

我终于堕落了，开始搞前端技术

作者 : admin 于 2009年06月29日, 04:31:13

2009
06-29

好久没买书了，周末烈日炎炎，购书一本。

我为什么总反对用微软的东西做企业级应用

作者 : admin 于 2009年06月26日, 13:01:02

2009
06-26

其实，我反对微软，只是反对他的不开源，蓝屏，其应用在中小企业项目中的性价比。

自从SAP里做开发的一个同学给我做了一个很简单的演示，让我彻底明白微软为什么围绕中小企业，甚至中小企业的产品都做不好。

简单目算一下，你有何感想。

大家在任意一个版本的excel上测试一下。这只是一个最简单的例子，如果你用.NET框架去做产品，可想而知，你的风险有多大。

再看google

精确度提升一个小数点，但这种处理差强人意，从数学上，33.3×3依然不等于百分之百。

初创公司的运维应该怎么做（lamp架构）2

作者 : admin 于 2009年06月24日, 18:08:39

2009
06-24

今天活进度不错，闲下来再扯几句，接上篇：初创公司的运维应该怎么做（lamp架构）

事情总得发展，一不小心就会发展到两台以上的服务器。

这时候，如何部署就是问题了，既要节约硬件带宽资源，省钱，又要充分发挥我们硬件的特性。

1、数据库，总得做个热备吧，主从复制，两个服务器就足够，当然更多的话，你可以多个从数据库。这时候主服务器挂了，备份的数据库可以立马变成主数据库进行工作，而主数据库又变成从的，这样达到无缝的切换。数据库多了，写压力集中在主数据库，而从数据库就可以分担读的压力。一般系统读压力大大高于写压力（特殊的系统除外），这样我们把其他服务器的CPU还能合理利用上。

2、如果但是数据库分到其他服务器上，CPU看似是充分利用了，带宽也得去利用。mysql同步走内网流量，自己用switch相连，而其他服务器同样可以分担http的负载。这时候，我们要考虑如何把原来独立服务器的http流量分布到其他新服务器上。直接做个nfs，把附件图片等分布到新服务器上是个最简单最懒的方式，也是短期最有效的，因为我们可以更换一个变量名就把url指向另外的服务器。

3、分频道也是办法之一，我们把一个大网站拆成几个小网站，分散到几个服务器，包括代码、数据、数据库，不过这种方法对小网站是费力不讨好，分开了，还整合不？分频道之外，还可以分功能，可以把email单独拿出来，也可以把一些消耗资源的功能单独拿出来。

4、最合理的，还是要综合考虑当前的服务，压力所在。把CPU、存储，带宽资源需求的模块都列出来，然后平均分布，再寻找平均分配资源的部署方式，这样是最优化的，但也对开发人员提出了更高的要求。程序代码的模块化、可零活配置、可迁移、可扩展是进行优化的前提。所以，在网站建设初期，最好考虑如何去扩展站点。

－－－－－－－－－－－－－－－－－－－－－

貌似运维跟程序又掺合到一起了，当然，好的项目是需要各部门合作的，团队力量总是大的，所谓：瘦死的骆驼比狗大。

初创公司的运维应该怎么做（lamp架构）

作者 : admin 于 2009年06月22日, 13:23:02

2009
06-22

这里说的初创公司，也包括一些小型的网络公司，运维是很头疼的事情。

初创公司，包括一些现金有问题的公司，资金紧张，买不起大量的设备，用不起高级的运维人员，财政捉襟见肘。

这种公司一个很重要的问题，就是要充分利用现有的资源，把每一分钱的效益都充分榨出来。

从技术上讲，大部分瓶颈都发生在带宽上，而大部分的灾难都发生在数据丢失上，底下，从以下两个问题来描述如何去搭建高效安全的小企业级应用系统。

单台服务器方案：

这样的公司实在是穷疯了，只有一台服务器，一个百兆共享。

配置：linux nginx mysql php 这是标配。单台服务器就别考虑负载均衡之类的东西了，只要保证http服务够快，充分去利用idc的带宽，跑高跑满是前期要做的。

如果只是网站，没有下载之类的，nginx是最佳的选择（做虚拟主机安全性太差）。这个时候，优化好mysql，搭配nginx优秀的性能，一般瓶颈优先出现在带宽上。

不建议把带宽跑得很满，因为idc一般都会在交换上限制流量，所以，不要等到相应很迟缓的时候再考虑增加带宽，如果带宽实在闲着没用，开个ftp，给员工做文档备份，装个邮件服务器，解决了内部沟通的问题。

数据安全，是一定要做的。mysql前期可以每天全备份，找个本地的机器每天下载备份，虽然浪费点人工，但不失为最安全的备份。如果本地都能搞丢……就拿块硬盘自己拍自己。

网站程序建议用svn版本控制发布，这样，就有了源码、svn库、本地开发三个以上的备份。而网站的附件，在程序编写前就得考虑增量备份的方式，合理设计存储结构，每天增量备份（因为附件多的话，每天全备压力会大）。而每天的增量，设计一个全备，一旦出现数据问题，有前边的全备，当日的增量，这样会把损风险和失降低到最低。

—————————————-

临时撰写，想哪里写哪里。希望有经验的一起交流。