easynetq

前言 通过前面的几篇文章，讲解了一个短信服务的架构设计与实现。然而初始方案并非100%完美的，我们仍可以对该架构做一些优化与调整。 同时我也希望通过这篇文章与大家分享一下，我的架构设计理念。 源码地址：https://github.com/SkyChenSky/Sikiro.SMS/tree/optimize （与之前的是另外的分支） 架构是设计的还是演变的？ 架构 该词出自于建筑学。软件架构定义是指软件系统的基础结构，是系统中的实体及实体（服务）之间的关系所进行的抽象描述。而架构设计的 目的 是为了解决软件 系统复杂度 带来的问题。 复杂度 系统复杂度主要有下面几点： 高可用 高性能 可扩展 安全性 维护成本 用户规模 业务规模 系统的复杂度导致的直接原因是业务规模。为了用户流畅放心的使用产品，不得不提高系统性能与安全。当系统成为人们生活不可缺一部分时，避免机房停电、挖掘机挖断电缆导致的系统不可用，不得不去思考同城跨机房同步、异地多活的高可用方案。 答案并非二选一 我认为架构，需要在已知可见的业务复杂度与用户规模的基础上进行 架构设计 ；伴随着技术积累与成长而对系统进行 架构优化 ；用户的日益增长，业务的不断扩充，迫使了系统的复杂度增加，为了解决系统带来新的复杂度而进行 架构演变。 因此，架构方案是在已有的业务复杂度、用户规模、技术积累度、人力时间成本等几个方面的 取舍 决策

　　MessageQueue，顾名思义消息队列，在系统开发中也是用的比较多的一个中间件吧。我们这里主要用它来做日志管理和订单管理的，记得老老大（恩，是的，就是老老大，因为他已经跳槽了）还在的时候，当时也是为了赶项目进度，他也参与开发了，那时候我才刚刚入职，他负责写后端这块，我来了就把他手上的任务接过来了，（接着接着……就辞职了）。 之后我们的开发仍然有条不紊的开发着，直到今年的一月份吧，才上线开始运行，然后就出现了常规状态，上线之后就开始爆炸， 这个页面打不开呀，那个内容没东西呀，第三方登录问题呀，支付问题呀，临时再改需求呀……（该来的都来了），加班、debug、测试、再debug……，然后经过几天的修复，终于完成了跟自己电脑一样稳定的运行，组员们都美滋滋的，今晚加个鸡腿才行。 都说祸不单行，古人是不会骗我们的，Bug怎么会修得完呢？天真，要是Bug能修得完还要我们来干啥，好景不长，果然，过了一周之后，组员突然群里叫喳喳， what is it ? 来了，今天的主角登场了，我也要开始加班了。 RabbitMQ 　　这个是今天要说的东西，基础概念什么的不是今天要说的重点，重点是： RabbitMQ 内存 暴 涨 ！ 使得整个服务器濒临瘫痪，远程登录服务器都差点挤不进去的状态，别看截图目前才1.3G，吃个午饭回来，就2.3G了，可怕不可怕？咋回事？ 老板喊你回来加班啦 　　先不管了