about Open edx distributed

premature optimization is the root of all evil. –Donald Knuth

##过早优化 似乎每个准备用Open edX的人，在安装尚未完成，用户还没注册，workflow还未确定，就开始担忧，如何分布式部署Open edX，以便能大规模应用呢？就好像明天用户就要破百万，后天完成第二轮融资，不提早考虑好，万一火了，多对不起排着队上课的同学呀

哈哈，没有开刷各位的意思，我自己一开始就是这样的（羞涩脸）

尽早考虑架构的问题当然是好的。毕竟一旦下手，生米煮成熟饭，再要调整就难了。

##Why not？ 不是说未雨绸缪有多不好，毕竟大家都觉得有备无患嘛，只是在Open edX中你不需要过早地担忧这些，Open edX采用了SOA风格的架构，RESTful风格的接口，基本是天生支持分布式的，这些都可以动态调整，初期不予考虑并但不影响你后期的扩展，而且你起步阶段还会敏捷许多

而一来就考虑分布式的问题，分散了精力不说，更要命的是：你其实不知道系统的瓶颈在哪里，你没有真实的使用场景，怎么知道压力在那里呢？

是分离数据库好呢，还是多搞几台缓存服务器好，如果优化mongo的话，cluster又该准备几个。

而后你发现，真实使用场景是在学校内部使用，学生集中在晚上8-9点，主要是看视频，而你折腾了半天mysql主从数据库，考虑了读写分离，同步延迟等问题，不是在闹么。。。读数据的压力缓存完全能应对，而视频流服务又独立于edx。

脱离实际使用场景的优化，都是耍流氓。

##定心丸 edX的架构风格有很浓郁的SOA风味，核心组件的接口都是RESTful风格。几乎天然为分布式做足了考虑。它允许我们敏捷得构建起服务，等到负载压力大了，找到瓶颈后再动态调整来应对。

对REST架构的扩展性有兴趣的同学，可以去翻阅Roy Thomas Fielding博士那篇著名的博士论文。那篇论文有中文版，我用了整个周末才读完 orz

ps：Roy这篇论文的结尾处，引用的一段，动人极了，二度引用以提升逼格

我们每个人在内心深处都怀有一个梦想:希望创造出一个鲜活的世界,一个宇宙。那些 处在我们生活中心、受到过专业训练的架构师们,都怀有这样的渴望:在某一天,在某个地方,因为某种原因,我要创造出一个不可思议的、美丽的、夺人心魄的场所,在那里人们可以漫步,可以梦想,历经很多世纪生生不息。 ——Christopher Alexander

原文更是动人

Each one of us has, somewhere in his heart, the dream to make a living world, a universe. Those of us who have been trained as architects have this desire perhaps at the very center of our lives: that one day, somewhere, somehow, we shall build one building which is wonderful, beautiful, breathtaking, a place where people can walk and dream for centuries. – Christopher Alexander

##实验 为了让大家宽心，我这两天在青云上做了如下实验

先以原生部署的方式，部署在单机（就是按官方wiki的的这个文档部署），而后假设用户暴涨, 然后我发现，这群人不知怎么搞的，读写很频繁，数据库压力挺大的，我最好把数据库分离出来。
话说用户暴涨的话，我不是该出任CEO迎娶白富美去了么，哪还写代码啊摔，哎想想还有点紧张。

我说干就干，参考了Preparation For Production Launch，在两台独立的机器上部署好了数据库，给与了相关的用户权限（为了方便，我都用了root，习惯不好囧），允许了外部访问，又在青云里设好了防火墙，之后修改了原先机器上（跑着edxapp）的配置，主要是各个*.auth.json文件里DATABASES相关的配置，指向新的数据库位置

然后把原先的数据导出再倒入到新数据库中，restart edxapp，一切OK！

主从数据库之类的还没做，参考网上的资料和这个项目，做主从数据库是不麻烦的

分离其他组件就更容易了，基本就是用ansible在相关机器上跑对应role，然后再运行edxapp的机器上配置好ip:port。把服务视为无状态为好，这样最有利于分离，而后分布

##关于瓶颈 前边我们提到，在真实的环境中找到性能瓶颈是关键，这是漏水最多的短板。

说来惭愧，这里分享下前车之鉴，我自己维护的平台，由于手写了比较多mongo查询，性能瓶颈都集中在这里了。达到过500%的负载，我也不知道这是什么鬼（服务器性能很好）

通过合适地采用缓存，完全消解了这个问题

所以，如果你写了很多自己的逻辑，尤其是大量与数据库打交道，做好缓存，做好缓存，做好缓存，重要的话说三遍。

##未来 如果你真的关心分布式，我是说真的关心，而不是玩票，好比你有一堆硬件，一堆资金，想据此提供云服务，有几个项目你可能会感兴趣

edX的分布式，当前官方只给出基于亚马逊云的分布式部署方案。此外也有几个很引人注目的项目，一个是官方开始倾注力量到docker中，这个可以在roadmap和黑客马拉松中看到进展和计划。当然不只是官方，appsembler团队在这条路上已经走得很远了，他们甚至尝试性地给出了基于kubernetes的方案

另一个是这里，hastexo正在将OpenStack技术用于Open edX

好啦 ，收尾， 看书去