系统架构与技术规划
文档说明
系统架构
本文把系统架构分为 业务架构 和 技术架构 两种来描述。两者是对同一个系统在不同角度的描述、侧重点不同。
业务架构，侧重于站在业务角度描述系统。重点是从业务角度对系统合理划分、清晰描述业务之间的依赖关系、业务所依赖的资源等。
技术架构，侧重于在技术实现角度描述系统。重点是对业务无关的通用技术架构的描述。
当前系统架构
业务架构
Note：
- 这里只描述了主系统、没有包含：菜小秘、冷链、以及其他几个静态站点。
技术架构
线上部署
线上有八台机器、除了测试机器外、都在这里。
为了描述方便、页面机器画了两次。
问题列表
- 自建DB、维护成本高。数据丢失风险大。
- 所有的表全在一个db里（mysql和mongo各一个db）、逻辑划分不清楚、维护难度高。数据量变大后不容易拆分部署数据。
- 没有严格分层、单模块架构为主。维护和扩展成本高。逻辑越来越复杂后、很难有单个人可以理解全部代码。
- 没有监控
目标系统架构
业务架构
技术架构
设计要点
-
尽可能的使用腾讯云提供的服务。
在系统发展的不同阶段、选择不同的运维模式。
- 起步规模：逻辑简单、产品少、数据量小、安全性要求低。 ---- 全系统自建。
- 中小规模：人力紧张、业务快速膨胀、无专职运维，数据安全性问题凸显、系统可靠性要求提高。 ---- 尽可能使用云服务提供的功能、集中人力投入到优化系统架构、性能和业务稳定性上。
- 较大规模：人力充足、业务较为稳定、有专职运维。 --- 在用云系统服务的同时、逐步考虑收回部分服务自己运维、尤其是数据安全部分。
-
服务发现与服务管理。
DNS模式简单：通用、不需要客户端做特殊逻辑。缺点是需要单独维护dns配置。
注册查询模式：需要客户端做专有逻辑，但是可以减少配置。
-
RPC模式
目前流行两种：rest和thrift。各有优缺。
-
系统扩展性
-
业务逻辑层
尽可能做到服务无状态、否则很难做快速的水平扩展。比如在服务代码的内存里直接做cache、就会保留状态、导致无法水平扩展。
-
DB层
db层的扩展主要是采用数据切分策略、扩展的好不好就看切分策略如何实施。在使用云DB的架构中、这部分需求压力变小。
-
-
LBS
LBS理论上必须做、至少要两台做互相备份。
系统演进
演进思路
-
不再挖坑
除了bug修复外、尽量不增加老代码复杂度、如果可能、以新代码代替。
-
新老代码间增加胶水层
用胶水层代码隔离新老代码、后期条件成熟、将胶水层替代为RPC调用。
-
分层--展现与逻辑
把展现与逻辑部分分层、有利于逻辑层的抽离。
-
识别可抽离逻辑策略
- 优先抽离变化频繁的代码
- 与代码其他部分相比、优先抽离有独特资源依赖的代码
演进过程
-
数据放入腾讯云DB、保障数据安全
系统重构的最重要事项是数据安全。如果数据安全不丢失、即使重构出问题、也有机会回滚。如果数据丢失、没法靠代码逻辑回滚。
-
增加系统监控
要可靠的重构系统、必须有完善的系统监控、可及时发现系统故障。
-
自动化测试
需要至少有些基础流程的自动化测试用例、这样在重构中能大大减少人工测试成本、大幅提高效率、降低出错。
-
渐进式微服务化
一个个服务的抽离。抽离服务代码、以及相关的DB表。