系统开发之设计模式
控制平面（control plane）和数据平面（data plane）分离
这两个概念几乎是大学网络课程的入门概念。Juniper上世纪末兴起的重要原因之一就是严格区分界定控制平面和数据平面，然后用ASIC实现数据平面。数据平面是指一个网络设备用于报文转发的模块，它的效率决定整个设备的效率，一般会由硬件完成。控制平面是指一个设备协议相关的部分，可以没有数据转发那么高效。
当你打开浏览器访问google时，互联网上面的网络设备就开始紧锣密鼓地工作，目的只有一个，把你的请求转发到google的服务器。学过网络课程的人都知道，这其中运行的网络设备就是路由器。路由器需要有足够快的转发速度，延时越小越好 —— 这考量的是数据平面的效率；而数据平面转发决策的依据 —— 路由，则由控制平面的协议处理来完成。
在一个互联网系统上，似乎没有控制平面和数据平面较为清晰的界定。我们不妨粗暴地认为用户访问的路径为数据平面，而管理相关的路径为控制平面。对于数据平面上的工作，我们可以单独划分一个集群来处理，力求每个请求都得到最高效地处理，而控制平面上的工作，则可以尽可能用比较小的资源完成。这里最重要的原则是：数据平面和控制平面做到路径分离，让数据平面上的大量请求不致于影响控制平面的正常工作；同时控制平面上的慢速任务不致于拖累数据平面的访问速度。
首次路径（first path）vs 快速路径（fast path）
做防火墙，少不了会遇到首次路径和快速路径的概念。防火墙处理的是双向的数据流，需要记录状态，所以有会话的概念。在首次路径里面，走一个完整的全路径，创建会话，在快速路径里面，则可以利用会话里面的各种信息快速处理数据报文。
在互联网系统上，类似的映射很好建立。在一个需要用户登录的系统里，用户登录的整个过程可以被视作首次路径，随后的访问可以被视作快速路径。
用户登录是一个复杂的过程，不仅仅是验证用户合法性这么简单。在前台尽快给出用户登录后页面的同时（响应速度很重要），后台需要加载一系列用户相关的数据到缓存（比如redis）中，以便用户在随后的访问中能够快速获取。加载的数据可以是用户的朋友信息，用户可能会访问的热点数据，各种各样的计数器等等。
当然，首次路径/快速路径的概念不仅仅适用于登录和登录后的访问，还有很多其它的应用场景。比如说一个规则系统，首次访问时从规则引擎中抽取用户相关的规则进行编译和缓存，之后的访问则直接从编译好的规则缓存中高效读取。
注意首次路径/快速路径的概念是相对的，就像分形几何一样，首次路径里面可以再区分中首次路径/快速路径，快速路径里也可以再区分出首次路径/快速路径，不断迭代下去。这样做的目的是，不断地优化系统中最常用的80%的路径，让它们的效率最大化。
慢速路径（slow path） vs 快速路径
慢速路径/快速路径和慢速路径/快速路径很类似，但又不尽相同。就用户登录而言，我们假定（或者有实际数据）80%的用户通过用户名/密码登录，那么用户名/密码登录就要置于快速路径下，而其它的诸如LDAP，OpenID，XAuth登录方式置于慢速路径下。
这样区分快速路径/慢速路径的好处是，一旦有需要，我们可以把对应的代码用更高效的方式实现，比如说整个系统是python实现的，系统中的一些快速路径处在用户访问的热点区域，那么可以考虑用go来实现。
基于队列的设计
在网络设备中，队列无处不在，几乎成了最基本的操作。一个数据报文从硬件上来之后被放到了driver的队列上，然后在系统处理的各个层级，不断地被入队/出队。队列有很多好处，比如说延迟处理，优先级，流量整形（traffic shaping）。
一个复杂的互联网系统很多时候也需要队列来控制任务处理的节奏。比如说email验证这样的事情，可以不必在当前的请求里完成，而放到消息队列中，由后台的进程来处理。另外，队列可以有不同的优先级，发送电子邮件和将图片转换成不同的尺寸显然可以放入不同的优先级队列中调度。
对于互联网项目而言，有很多成熟的消息队列系统，比如RabbitMQ，ZeroMQ。
流水线
在网络系统里面，如果一个任务很复杂，需要很多CPU时间，那么该任务可以分解成多个小任务来执行，否则的话，这个任务占用CPU时间过长，导致其他任务无法执行。当一个任务分解成多个小任务后，每个小任务之间由队列连接，上一次处理完成之后，放入下一个队列。这样可以任务调度更均衡。
在互联网项目中，流水线有很多应用场合。比如说一个工作流里面状态机的改变，可能会执行一系列的操作，然后最终迁移到新的状态。如果这一系列的操作在一个大的函数里执行，而非分解成若干个通过队列相连的小操作，那么整个处理过程中的慢速操作会影响整个系统的吞吐量。而且，这样做非常不利于并发。
在一个大型系统中，流水线的程度决定了并发的程度。而流水线的应用程度会影响整个系统架构的吞吐量。有些编程语言，如golang，天然就让你的思维模式往流水线的方式去转（通过go/chan）。
有限状态机
既然提到了状态机，就讲讲状态机。状态机由两个元素组成：状态；以及状态迁移。状态迁移是由动作引起的，因此一个状态机可以表示为 state machine = {state, event} -> (action, new state)。只要画出一个二维表，就能分析系统所有可能的路径，而且很难有遗漏。在网络设备中，大部分协议都由状态机来表述，比如说ospf，igmp，tcp等等。
在互联网项目中，状态机无处不在。比如说订单处理。一个订单的处理流程用状态机表述再完美不过。下面是我曾经写过的一段示例代码（python）：
ORDER_EVENTS = {
(const.ORDER_EVENT_PAYED, const.ORDER_STATE_CREATED): {
'new_state': const.ORDER_STATE_PAYED,
'callback': on_order_event_payed,
},
(const.ORDER_EVENT_PAY_EXPIRED, const.ORDER_STATE_CREATED): {
'new_state': const.ORDER_STATE_CANCELLED,
'callback': on_order_event_cancelled,
},
(const.ORDER_EVENT_CONFIRMED, const.ORDER_STATE_PAYED): {
'new_state': const.ORDER_STATE_CLOSED,
'callback': on_order_event_confirmed,
},
(const.ORDER_EVENT_CONFIRM_EXPIRED, const.ORDER_STATE_PAYED): {
'new_state': const.ORDER_STATE_CLOSED,
'callback': on_order_event_confirm_expired,
},
...
}看门狗（Watchdog）
最后稍提一下看门狗。一般来说，路由器防火墙这样的网路系统是实时系统，任何一个任务，都应在规定的时间内结束，否则就是系统错误。所以我们需要看门狗来监控任务（有硬件看门狗，也有软件的）。看门狗还可以帮助开发者发现系统中的死锁，过长的循环，任务分配不合理等问题。如果某一任务执行时间过长，它就会阻塞其他任务，如果所有的CPU都被这类任务占用了，系统就无法响应事件，也有可能无法将这些任务调度出去。
在互联网项目中，处理请求，处理 异步任务等等都有一系列数量有限的进程。如果某个进程死锁，或者执行时间过长（可能是异常情况）导致「假死」，我们可以用看门狗进程来杀掉这些已经「假死」的进程，让系统的吞吐量恢复到正常水平。如果不这样做，「假死」的进程越积越多，可能会最终导致整个系统无法工作。
