Mikel
可靠、高吞吐架构基础改造
前言
在互联网应用项目中分布式设计是必不可少的环节，通过分布式设计从而达到简单扩容硬件的方式来提高系统和平能的总体吞吐能力。但实际应用中并不是简单地进 行分布式设计就能解决问题，因为在现实应用并不是所有硬件资源都可以很好地进行扩容，比较常见的就是数据库资源，所以在设计整个架构的时候必须考虑部署资 源的局限制性；否则整个构架所产生的效果就不能达到设计前规划水平。下面讲述构建一个可靠、高吞吐的分布式业务架构基础改造。
现有架构
以上结构是最常见的分布式设计结构，而我们现有项目也是遵循着这种结构。这种结构看上去似乎比较理想，通过添加的硬件就能支撑所需要的访问量；但这种架构在实际应用中不一定达到效果，还容易导致服务不具备良好的可靠性；主要原因如下：
数据库资源
在整个体系环境中数据库资源往往都不具备水平添加设备的可行性，所以即使上层硬件资源再充足也是无补于事的。虽然可以通过业务来水平拆分数据，但过多的数据库实例在业务处理同步上也会导致整个数据库环境非常复杂影响效率。
同步操作
以上结构的请求逻辑到响应都是以同步的方式，同步方式的缺陷也是非常明显的，在整个业务线 上只要有一个点存在效能问题那上游上的所流入都会被阻塞，这个阻塞最终会影响到最上层导致用户请求无法响应。同样上游大量请求进来，也容易导致这个点出现 崩溃导致整个系统瘫痪；一旦这情出现即使你如何添加硬件资源也是无法支撑。
问题总结
以上两点就已经说明了在架构设计的时候需要考虑情况的多样性，一旦有些应用层面的问题在设 计上没有考虑到那这个架构体系就达不到预期的设计目标。所以在作为架构人员了解业务知识，数据流向，支撑产品选择,系统支撑目标和实施规划是一件非常重要 的事情，反而代码细节层面的设计变得相对次要些了。
改进架构
在高并发应用中数据库资源往往是很短缺的，而这资源确是高并发洪峰的问题点所在,如果在架构阶段没有考虑这些情况那就会产生很较严重的后果,就像平常我们 听到的什么XX年一遇的洪水一样.以上的设计架构就没有考虑洪峰的情况。在现实生活中人们都会在河流上设计堤坝来抵遇这此情况的发生，而这方法在软件架构 设计中也是非常有效的。
当下游的排水能力不足的情况，为了应付上游大量洪水涌入必须建立一个蓄水池。在架构中可以架设一个MQ服务用于积蓄消息的信息池。当用户提交处理数据系统 会直接把消息投递到MQ后就可以给用户确认，这样用户的响应时间缩短整体吞吐会提升N个级别；由于有MQ的隔离下游的逻辑处理就可以根据资源的使用情况， 可达到有序可靠的处理能力。
针对以上情况调整的架构体系如下：
通过以上架构的调整，上层应用就不会受限于数据库资源的缺少而影响。在不调整数据库资源的情况可以通过扩容中间部件资源来达到更高的吞吐效能和并发支撑能力。
异步
业务异步处理可以很好地解决抗并发处理能力，在不需要等待复杂的业务处理的情况下可以大大缩短响应时间，提高吞吐量。
MQ
MQ在软件系统中可以很好的承担消息积蓄池的作用，它可提供高信息吞吐和可靠性的优点；通过它可以把业务消息和数据库进行一个很好的隔离支撑。
NOSQL
NOSQL产品有着其查询高效性的优点，而这些效能往往是传统关系数据所不能比的；通过它可以很好地隔离大量数据查询时的数据库瓶颈问题。
总结
以上架构的总体出发点都是缓解数据库压力而设计的，而它并不能满足所有系统的需要，只是针对我们现有系统面临问题的基础规划。由于架构设计是为了让系统可 以更好的支撑相应的业务功能；所以架构设计前必须明确业务规则和业务指标，只有在这基础的构建才能保证架构的可靠性。在传统技术人员来看，架构往往是如何 把系统的代码规划好，制一个良好的代码层次规则。但架构规划更多的系统生态圈的支撑，所以考虑的面要比代码层面要高很多，具备业务的深度和技术的广度是非 常必要。
当然我自身也不具备架构师的资格，以上只是这些年来做架构所积累的一些经验分享出来，今后有时间会把这些年涉及B2C各个系统架构设计分享出来。
开源多台平通讯组件
个性化网站信息收录和订阅平台
C#组件设计交流群：47164588
C# socket :136485198 微博http://weibo.com/ikende
