大规模业务服务器开发总结
大比小好
开发阶段，服务不稳定，一个大服务不如一堆小服务; 运维阶段，服务都稳定了，一堆小服务又不如一个大服务。
大规模的时候了，如果能够一个进程搞定的，尽量不要拆两个进程。
少比多好
如果都是大服务，自然而然地，服务数量就少。
服务数量少，运维成本就相应低。
快比慢好
一个进程，跑得越快，qps越高，所能使用的资源越多，越能“物尽其用”。
直连比队列好
常见的进程间内网通讯，一般会使用直接的rpc或者是mq来中转。然而，在一般的情况下，引入mq会给服务化带来复杂度，使容量问题更加隐藏。
特例监控比共性监控好
强烈要报警的监控一定要是开发手工加到代码里去的，只要报警，一定是了可用性降低，不应该有二义性。共性监控如cpu、硬盘、内存等，只能算是知会性的报警，一般不会影响业务的可用性。
进程外负载均衡比进程内好
负载均衡逻辑放到一个进程的好处在于，这部分逻辑不常改动，同时不应该受经常上线的影响，最好是7_24_365全天候足够稳健的服务。进程内的问题在于，当业务代码与负载均衡代码改动频率完全不是一个量级时，双方都将在上线，同时任何一方的问题都将相互影响; 更大的一个问题是，推动所有服务一起更新负载均衡策略难度远大于更新一个专门的进程。
有层级的服务比普通SOA好
SOA要求我们把各业务逻辑服务化，没有层级的服务化就是噩梦。主要服务之间一定要有金字塔一样的规则，否则会对各种跨机房、迁移等带来麻烦。
kv存储比RDS好
只用kv，存储层维持状态，扩展、迁移都大大降低难度。使用rds，qps变化时延迟并不是线性变化，kv就能保证这点。维护状态的一层大多在db，以kv这样容易扩展的方式，更加利于未来的迁移和扩张。
无状态比有状态好
服务带上状态，以后迁移、扩容各种毛病，只要有一个理由可以不要状态，就一定要无状态。
闭源比开源好
开源项目都是解决共性需求，规模越大，越是有特性，越不可能开源，闭源可以省很多事。
原创文章如转载，请注明：转载自五四陈科学院[http://www.54chen.com]
Posted by 54chen cloud