通用高性能服务框架解析

做了多年的后台服务，1直想将自己这么多年对高性能服务架构的1些粗浅认识写出来，1方面对自己这个阶段成长做个总结， 另外一方面想通过这个与各位做1个交换，妄不吝赐教。

1、最初对服务架构的概念

最初接触服务端程序应当是2011年，当初基于服务架构的概念是基于这样1个模型

这是最简单的1种C/S模型结构，客户端直接连接服务端，只能适用于对效力、并发量、扩大性要求低的环境，所以当要求量逐步上升，你会发现这类架构的系统，在处理上已不满足业务的需求了，所以你衍生出下面1种架构。

2、多个App分流模式

这是1个两层框架，中控层是控制服务只做转发分流操作，分流的算法通常是轮询，具体可以根据实际的业务情况去制定。利用层是具体的利用服务，履行具体业务。这类架构的主要优势有1下几点:

1、中控层将流量有效散布到各个业务服务，而中控层的利用只做转发不做业务，在处理要求量上效力要远远高于直连业务服务，所以框架相对上面1个在吞吐量上大幅增加

2、较易于扩大，如果发现利用服务不能支持现有业务量时，可以通过增加利用服务来分流。

但是这个种架构随着业务量的增加也会渐渐不适用，有同学可能会说多弄几个业务服务分流不就得了，这里得斟酌到资源本钱，管理本钱等等问题，所以这类方式在大要求量下是不适用的，问题就在如何提高利用服务的业务处理速度，我们可以引入缓存机制。

3、加缓存机制的框架

在普通业务处理上，查询要求量是最多的，如何提高查询效力，就成为关键，1般情况下数据库或磁盘IO的读取都能成为瓶颈，所以常常我们会在业务利用与数据库或磁盘之间添加缓存机制，业务利用先去查缓存，缓存没有再去查对应的数据库或磁盘，90%的要求都能在缓存中解决，这样不但减小了数据库的压力，同时也增加业务处理的速度。固然你可能会根据业务的需要多几个缓存，但是基本的思路不变，具体根据你的业务走，此种架构基本能解决80%的问题。

4、加入容灾机制的框架

上面所讲的框架只是1种基础框架，在实际利用中需要斟酌的因素很多，比如服务器宕机了，怎样平滑过渡，不影响业务等等，这里就得加入容灾机制。

监控服务主要负责监控负载均衡服务是不是有宕机情况，如果有，置为相应状态，客户端要求监控服务，获得有效的负载均衡服务的地址，进行连接，这样即便有1个服务宕机，其实其实不影响全部系统的运行，固然还有数据库的容灾，这里就不多做讨论了！

5、总结

影响全部系统性能的因素有很多，这里仅就框架上做了1些粗浅的讨论，抛砖引玉，实际情况可能斟酌的因素会更多，至于常见程序上的优化，有时间我也会写1篇文章总结1些。另外高性能WEB利用的框架搭建可以参考这篇文章：http://www.csdn.net/article/2014⑴1-06/2822529 。 总之增加系统性能的不变原则就是如何快速的处理业务数据。

最后，大家有甚么问题或好提议，可以加入群：291368579