关于架构的一点思考(一)

上几天，以前公司一个同事在Q群上发了一个《高性能存储平台设计文档》，说请大家帮忙看下，指点一下。

下图是这个设计里的【系统主体架构图】：

看了当即觉得有点蛋疼。

首先是网关那里，使用的是PHP来做守护进程；其次数据节点使用MongoDB和MySQL来做主从，对，你没看错，可是MongoDB和MySQL怎么做主从？那哥们说，利用PHP做控制。

对于这个架构，我不怎么给面子，直接批为不行。那哥们跟我一样，只懂PHP，不懂C++，所以会写出这样的架构也就不奇怪了。但是即使是不懂C++我也知道，要做到高性能不能用PHP。PHP 1.不支持多线程，2.进程非常笨重，加载的东西太多，3.解释性语言运行速度比C++慢一个数量级，4.长期运行稳定性差。5.而且要做到高并发最好是使用epoll模板，要使用epoll模型就要用到libevent，据我所知PHP是没有这个扩展的。单靠PHP自己的话，估计几百个并发就将网关的内存和CPU耗尽了。

我问那哥们这个模型的一些关键点如何处理：

1.选择节点的一致性hash算法是怎样的，如何保证SELECT和UPDATE操作的数据在同一个节点上。

2.MongoDB和MySQL间的数据主从同步如何保证，出现异常如何处理。

3.MongoDB缓存数据的淘汰机制如何考虑。

4.由于MongoDB和MySQL的操作是异步的，能否保证异常的情况下，数据在MySQL端不丢失。

5.每个节点可以达到多高的读写性能。整个系统总体的读写性能又如何。

哥们无法很好的回答以上的问题，我看出来他只是将一些很棒、看起来好玩的技术拼合在一起而已。

其实我以前也经常像我那哥们一样，不满足于做单调乏味的运营开发工作，希望在技术上往横向和纵向不断发展。可是受限于自己的知识和技能，所以往往会向一些看上去更浅短易懂的方向去做尝试。例如画系统架构图就是一个看上去比较简单的、又让人觉得是比较牛B的工作。一想到自己设计的架构可以支撑海量用户，一股成就感就涌上心头。

后来一次跟组长tenfy和总监minos的谈话让我的困惑顿结。那是在一次方案评审会上。我在数据层的设计上，担心服务器承受不住压力，所以打算使用cache。不过这样做就会增加系统复杂度，要考虑处理各种cache和DB间的异常情况，拉长开发时间。但是minos和tenfy否决了cache方案，说直接查询MySQL就行了。minos向我们解释，淘宝在查询个人订单的时候，就是直接读数据库的。如果使用cache的话，就会有cache数据和DB不一致的问题需要解决，复杂度大大增加了。可是直接查DB不担心服务器压力的问题吗？minos说淘宝做过统计，用户查看个人订单的访问次数很少，直查DB完全可以撑得住这个量。

会后tenfy又跟我们说了系统架构设计方面的一些经验。他问我们，知道我们外网DB服务器平均每秒可以处理多少次查询请求吗？如果使用了cache后，又可以支撑多少次查询请求？系统的最高并发是多少？知道我们的网站现在一天的PV是多少吗，高峰值是多少？要支撑目前的业务，最好使用哪些技术，而这些技术的性能又是如何，极限值是多少，优点是什么，缺点又是什么？要支撑每天的访问高峰，至少需要几台机器？而这些机器间应该用什么技术去联合成一个架构，DB主从？LVS？每种架构的性能表现又是如何，优点和缺点又是什么？成本呢？

对于以上这些运维数据，我是一点都不清楚的，而tenfy则几乎都能说出这些数据的一个大概值。tenfy说，只要对所有的这些数据了然于心，在设计项目架构的时候就能很快想出在成本、性能、时间、复杂度等权衡最优的架构。从这里可以看出，设计架构这件事并不是简单的画图，也不是简单的将一些技术拼合起来，更不是拍脑袋的事情。它是需要根据实际数据分析后才能决定的事情。