凌晨我们更新了服务器端，本次更新抛开功能等因素，但在技术架构方面更为合理的使用了 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 账号）