做了多年的后台服务，一直想将自己这么多年对高性能服务架构的一些粗浅认识写出来，一方面对自己这个阶段成长做个总结， 另一方面想通过这个与各位做一个交流，妄不吝赐教。
一、最初对服务架构的概念
最初接触服务端程序应该是2011年，当初基于服务架构的概念是基于这样一个模型
这是最简单的一种C/S模型结构，客户端直接连接服务端，只能适用于对效率、并发量、扩展性要求低的环境，所以当请求量逐渐上升，你会发现这种架构的系统，在处理上已经不满足业务的需求了，所以你衍生出下面一种架构。
二、多个App分流模式
这是一个两层框架，中控层是控制服务只做转发分流操作，分流的算法通常是轮询，具体可以根据实际的业务情况去制定。应用层是具体的应用服务，执行具体业务。这种架构的主要优势有一下几点:
1、中控层将流量有效分布到各个业务服务，而中控层的应用只做转发不做业务，在处理请求量上效率要远远高于直连业务服务，所以框架相对于上面一个在吞吐量上大幅增加
2、较易于扩展，如果发现应用服务不能支撑现有业务量时，可以通过增加应用服务来分流。
但是这个种架构随着业务量的增加也会渐渐不适用，有同学可能会说多搞几个业务服务分流不就得了，这里得考虑到资源成本，管理成本等等问题，所以这种方式在大请求量下是不适用的，问题就在如何提高应用服务的业务处理速度，我们可以引入缓存机制。
三、加缓存机制的框架
在普通业务处理上，查询请求量是最多的，如何提高查询效率，就成为关键，一般情况下数据库或者磁盘IO的读取都能成为瓶颈，所以往往我们会在业务应用与数据库或者磁盘之间添加缓存机制，业务应用先去查缓存，缓存没有再去查对应的数据库或者磁盘，90%的请求都能在缓存中解决，，这样不仅减小了数据库的压力，同时也增加业务处理的速度。当然你可能会根据业务的需要多几个缓存，但是基本的思路不变，具体根据你的业务走，此种架构基本能解决80%的问题。
四、加入容灾机制的框架
上面所讲的框架只是一种基础框架，在实际应用中需要考虑的因素很多，比如服务器宕机了，怎么平滑过渡，不影响业务等等，这里就得加入容灾机制。
监控服务主要负责监控负载均衡服务是否有宕机情况，如果有，置为相应状态，客户端请求监控服务，获取有效的负载均衡服务的地址，进行连接，这样即使有一个服务宕机，其实并不影响整个系统的运行，当然还有数据库的容灾，这里就不多做讨论了！
五、总结
影响整个系统性能的因素有很多，这里仅就框架上做了一些粗浅的讨论，抛砖引玉，实际情况可能考虑的因素会更多，至于常见程序上的优化，有时间我也会写一篇文章总结一些。另外高性能WEB应用的框架搭建可以参考这篇文章： 。 总之增加系统性能的不变原则就是如何快速的处理业务数据。
最后，大家有什么问题或者好提议，可以加入群：291368579
当你下定决心准备出发时，最困难的时刻就已经过去了。那么，出发吧。
