基于 AWS 的架构

凌晨我们更新了服务器端,本次更新抛开功能等因素,但在技术架构方面更为合理的使用了 AWS,趁现在有空,做点笔记。

最早的架构

最早的架构非常简单,在一个 EC2 实例里跑了所有的服务(Web / Web Service / 数据库),只是用 nginx 简单做了一下负载。

这种架构是初创项目的基本架构,好处是省钱,但坏处是显而易见的,比如服务器挂了或者被端了,就一切玩完,而且这并没有使用 AWS,只是把它当着一个服务器来使用了。这种方式在生产环境下运行了一个月不到,就做了一些调整。

第一次调整

这次的架构调整也没有做太多的事情,只是按功能做了下划分,从之前的一台 EC2 实例变成了两台,Web / Web Service 和数据库各一台。在数据库服务器上引入了备份机制,在负载均衡上引入了 ELB,算是用到了一点真正云计算的东西,同时把动态数据和固态数据做了区分,并在服务器上引入了机器人监管程序。这种方式一直运行到今天凌晨。

第二次调整

也就是今日凌晨的调整,这次调整算是比较大的一次调整,在调整前,规划的目标是高并发且无宕机的服务。

我们主要用到了 EC2,RDS,ElastiCache,S3,具体它们的作用可以看 AWS 上的说明。

小帖士:很多人习惯了密码,不是很喜欢密钥的登录方式,其实在创建时候,比如 EC2,在高级选项的时候,输入下面内容

#cloud-config
password: your password is here
chpasswd: {expire: False}
ssh_pwauth: True

update@20171018 : 粒子化 UnitServer 架构

因为业务场景变更,我们的架构也做了一些变更,比如把结算中心给独立出来了,之前我们一直用的是 unitserver 的架构,这个架构是我 2011 年做的一个设计,它的产生是因为早些年我做外包,人手不够,研究发现服务器端重复率很高,为了快速开发,就设计了这么一个架构。形象一点说,它是一个五脏俱全的小麻雀,基础技能具备,当业务扩展,就像是给这个小麻雀加各种装备,这种架构相对比较简单。

这个架构另外一个特点就是分布式,当服务中 unitserver 出现问题时,会自动切换到任意一个没有问题的 unitserver,每个 unitserver 之间的数据是自动同步的,所以当切换后,不会出现数据不对的问题。而且它还有一个好处是会根据客户所在地方,连接离他最近的 unitserver,很好的解决了当年的所谓南北线路不同的问题。

这次我们做的事情是进一步细粒化 unitserver,根据不用的服务拆分成不同的颗粒,引入了 microservices 的概念。

实现的效果是:

  • 每一个粒子化服务单元之间是对等的。

  • 去中心化,尤其是数据。

  • 每个服务单元都可以专注于做自己的本质工作。

想到小时候的一个动画片《战神金刚》,每个都是一个独立的战斗个体,但合体又是一个强大的合体。unitserver 却有很多个这样的合体。


> 可在 Twitter/X 上评论该篇文章或在下面留言(需要有 GitHub 账号)