对于中小型互联网架构设计的讨论

三阶魔方 发布于 2014/05/21 20:04
阅读 1K+
收藏 18

笔者就职于一家小型互联网服务公司,对现有服务架构出现的问题有一些想法。现在就把这些想法说一说。

我们不是淘宝,没有那么牛的技术团队,也没那么多的服务器,解决问题的方式就是:

出现问题 -> 思考方案 -> 尝试解决 -> 解决问题。

现有的服务架构呈金字塔型,如下所示:

基础层服务(1台服务器)<->应用层服务(5台服务器)<-> Nginx(1台服务器)

  • 基础层服务处理最核心的业务逻辑,主要进行数据库交互。
  • 数据库有2台,写操作在主DB上进行,读操作在从DB上进行。
  • 在应用层服务使用了缓存设计,共享2台Memcached服务器。

这种架构设计的优点:应用层服务使用了5台服务器,实现负载均衡的同时,还保证了在某台服务器挂掉的情况下,另外4台服务器能够支撑起来,使服务不间断。另一个好处是,部署过程更加容易:先摘出一台服务器进行部署,部署完成后放回去,接着摘出另一台服务器进行部署,部署完成后放回去……直到5台全部署完。这个步骤使用自动化部署脚本,过程安全可靠。

但是缺点也很明显:

  1. 基础服务层的压力较大,如果挂掉,将直接导致所有服务中断。
  2. 另外,数据库压力很大,虽然进行了读写分离,压力仍然很大。
  3. 同时,主从不同步的问题在很多场景频繁出现。

改造的目标为:不再使用金字塔式结构,而是通过业务类型切分为不同的服务。即使某个服务挂掉,并不会对其它服务造成影响。将数据库根据业务类型拆分成多个,缓解数据库压力。

我画了一个示意图,一直不会画这种东西,凑合看吧:

目前只是我自己的个人想法,还未付出实施,各位大拿有何高见,还请不吝赐教!@红薯

加载中
0
netkiller-
netkiller-
笔者” 应该叫 “键人”
0
cgcgbcbc
cgcgbcbc

显然首先要避免单点故障,ngnix服务器一挂全都完蛋

0
肥皂泡2
肥皂泡2
先摘出一台服务器进行部署,部署完成后放回去,接着摘出另一台服务器进行部署,部署完成后放回去……直到5台全部署完   这个部署有问题把!!!,新部署的和原来的 业务逻辑不一样 咋办?
幻影浪子
幻影浪子
同感
0
Jack_Q
Jack_Q
服务这块的通信,要考虑并发,事务,安全,集群等方面的因素。
0
幻影浪子
幻影浪子

我觉得现有架构更好。

现在要做的是强化基础层。话说这一层就相当于淘宝用Java写的Web Service层吧?

0
一笑居
一笑居
楼主分布式缓存单点故障如何考虑的呢?nginx也做一个集群吧,不然你后端再强大,nginx挂了网站也等于挂了
返回顶部
顶部