通用高性能服务框架解析

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

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

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

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

二、多个App分流模式

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

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

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

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

三、加缓存机制的框架

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

四、加入容灾机制的框架

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

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

五、总结

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

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