分布式架构有点太大了, 我们还是主要关注基础服务集群方面的开发技术吧...
1, 服务端微架构上我们是完全可以实现: 单线程 + 异步 +等待但不阻塞 的事件框架的, 从nginx/lighttpd的异步事件框架如何与fcgi module协调工作就可以掌握其原理, 所以我们是有能力开发一个逻辑中转服务端, 作为一个反向代理进行工作, 保证请求的接入->转发到具体业务服务端->从业务服务端接受应答->将应答转发回客户端.
2, 在1)的基础上, 并不是所有业务都可以实现立即响应, 可能有的事情要处理1小时, 我们不能借助1中的实现手段解决此类问题, 因为客户端并不一定喜欢阻塞1小时等待你的应答, 虽然我们的服务端有能力异步的接入足够多的并发请求.
这时候, 如果我们能够给客户端提供推送通知或者提供询问接口是一种常用设计, 还是要提到买火车票的问题, 铁道部都会用买票排队这种手段降低DB的负载, 何况我们...
我们需要借助高效的中间件来完成一些事情, 在这方面我们主要是架构师, 不是码农...(说出来都嫌丢脸..)
比如我们都知道用消息队列, java用activemq... c(python/php)用zeromq, rabbitmq, memcacheq...
消息队列是干嘛的? 容量无限(可持久化到磁盘), 没有关系型数据库的复杂所以读写效率高(一个queue一个queue, 能有多复杂呢), 支持订阅与发布模型很容易扩展, 等等.
借助消息队列, 我们可以简化编程, 开发生产者, 开发消费者, 消费者完成业务逻辑并通知客户端(客户端开个端口监听不就得了?)/存DB, 所以还是挺好玩的.
3, 还有种模型, 就是XMPP这种天生聪颖的协议+jabberd2这种天生聪颖的架构了. 如果客户端始终维持一个到服务端的长连接来发送命令和读取应答, 那么前两种方案弱爆了, 我们不如把业务迁移到XMPP集群中去, 我们只要开发服务型的客户端连接到XMPP集群, 就可以为客户端型的客户端提供发布与订阅(新闻推送?), 或者普通的一问一答了, 因为客户端是长连接的特点, 谁也没强迫谁要在多少时间内应答, 就算不答又怎样? 在XMPP里, 请求和应答从来都不是"一问一答"的, 所以这真的是种特殊的工作模式, 并且很常见, 比如IM. |