阿里8年资深技术专家谈企业级互联网架构的演进之路

正文

请到「今天看啥」查看全文

当时用的是小型机+Oracle，CPU90% 以上，每年宕机最少一次。 这主要是因为有大量新业务写入，两周一次的频度，不断地有新 SQL 产出。

在新的 SQL 中，如出现一个慢 SQL，就会出现宕机。当时我们用的小型机重启一次需要 20 分钟，切换到异地也是 20 分钟。

关于连接数问题 ，如下图：

当时后端 Oracle 的连接池有限，约 8000 个左右，一旦超过就会出现问题。因为超过数量，链接占的内存会非常大，且连接数单点风险系统很高。

阿里面对 DBA 相关问题的应对方法

---

综上所述，当时阿里 DBA 面临维护人员很多，团队职责不清、数据无法共享，团队各自为战、小型机数据库压力过大，连接数单点风险系统很高等问题。

好在阿里那时正处于增长期，所以这时通过招聘一些技术大牛来解决问题。

基于 EDAS 进行服务化改造

针对阿里 DBA 遇到的问题，从硅谷请来的技术人用服务化的方式试着解决。当时在中国只有用友做过服务化，且效果不是很好，没有借鉴，只能谨慎小心的自己往前走。

如下图，是 阿里以服务化方式将系统专业分工的三个关键战役 。

用户中心服务化

选择用户中心的第一个是做服务化，因为用户中心是最小集合，最简单清楚，还因为确实有业务需求，也是想要验证这条服务化的理念是不是正确。

服务化之前的用户中心，有六个不一样的查询方法，看起来遍历的方式差不多，但可能某个参数不同，因为数据来自不同的团队。

服务化的原则是能不改不改，能简化简化，采用的传输方式是 HTTP。然而，这样做行不通，是因为除了服务化 HTTP，其他内容没有改变，就需要布设 Load Balance。

为了保证 Load Balance 尽可能稳定，所以选择硬件 F5 来配置。把前端进入的用户流量打到 F5，额外在增加新 VIP 接口，请求通过 F5 转出去。

这里发现一个很严重的问题，就是每当用户登陆一次，出现一个节点，跳转一次流量就要增加一倍。但 F5 是很贵的设备，未来如果所有都变成服务化，用 F5 就不可行。

请到「今天看啥」查看全文