关于web服务器架构的思考

关于web服务器架构的思考

笔者最近一年都在从事企业私有云存储的开发，主导并推动了服务器架构的重构。在架构演化的过程中，有了很多的心得体会，这里记录一下，算是对自己架构成长的一个总结。

原则

对于笔者来说，设计一个web服务器架构方案，最先考虑的就是简单以及可扩展性。而这两个也是笔者设计架构的首要原则。

简单

对于一个企业级web产品来说，它其实是由非常多的基础服务来组合起来的。以私有云产品来说，如果想实现一个简单的文件共享功能，至少需要共享服务，文件服务，账号服务三个服务来共同实现。

• 共享服务，用来管理文件共享关系，如用户A给用户B共享了一个文件abc.txt
• 文件服务，用来提供共享文件下载，如用户B需要在哪里以及如何下载abc.txt这个文件
• 账号服务，用来提供共享人员的相关信息，如用户A和B的账号，姓名等信息

上面三个服务，缺少了任何一个都不能实现共享功能。但是为了实现一个功能就要与3个服务进行交互，有些童鞋就觉得非常麻烦，简单起见，他们将其糅合在一起，这样就能很好的进行代码编写了。但是这样做的弊端也非常明显，可维护性非常的差，因为功能都是耦合在一起了，如果这时候我们想用另一套企业自己的账号数据，那么完全无法实现。

上面说的只是笔者列举的一个例子，实际项目中，共享功能还是很好的进行了切分，但是仍然有很多功能过于耦合，以至于笔者的团队在很长的一段时间里面都在为以前的某些童鞋的错误设计买单。

鉴于有了上面的经验教训，笔者在考虑架构方案的时候最先想的就是简单。

所谓简单，其实很好理解，就是一个服务就干一件事情，不同的功能逻辑别糅在一个服务里面实现。更上层的服务是通过集成底层的服务来实现。其实这个就跟程序设计里面模块化的思想一样，只不过这里的模块就是单个服务。

一个服务一个模块，好处是很多的，但也不可能100%的完美，仍然很多问题需要考虑，譬如：

• 服务的可用性问题，如何判断一个服务是否可用，以及当机服务的恢复。
• 服务的运维管理问题，系统可能随着功能的增多而有了太多的服务，对这些服务的监控管理就是一个很难的问题，毕竟每个人都不希望凌晨因为服务当掉了这些问题被电话叫醒。

上面的这些问题，笔者认为已经涉及到服务的高可用问题了，与是否