| ... | ... | @@ -4,7 +4,7 @@ |
|
|
|
|
|
|
|
## 现状
|
|
|
|
### 核心系统
|
|
|
|
现状咱们有一套主流程相关的系统，主要包括赛事系统（主机）、运动超市（小程序）、产销后台、产销接口、定制发货、仓库管理。
|
|
|
|
现状咱们有一套主流程相关的系统，主要包括赛事系统（主机）、运动超市（小程序）、产销后台、产销接口、定制发货、仓库管理等。
|
|
|
|
### 附属系统
|
|
|
|
主要包括CRM、账号系统、同步程序、生产拍照、3D设计工具、2D设计工具等等。
|
|
|
|
|
| ... | ... | @@ -18,10 +18,40 @@ |
|
|
|
## 思路
|
|
|
|
为了应对这些变化，我觉得开发团队方面，我觉得一定要集中优势力量，采取小步快跑的策略。主要是以下方面：
|
|
|
|
1. 开发人员集中起来，所有人理解所有要做的业务，然后共同来完成设计和编码。
|
|
|
|
1. 第一优先级是做新功能，在现有系统的基础上。
|
|
|
|
1. 在做新功能的时候，不断优化原有的设计
|
|
|
|
1. 做新功能，在现有系统的基础上。
|
|
|
|
1. 在做新功能的时候，不断优化原有的设计，比如把一些数据库表从主库中剥离。
|
|
|
|
1. 充分利用事件（mq）进行解耦。把服务间的耦合度降低。
|
|
|
|
1. 逐渐把核心系统与辅助系统融合起来（不是变成一个大单体服务），比如实现统一登录、增加门户等，避免碎片化。
|
|
|
|
1. 逐渐把核心系统拆分出更多的外围服务，形成有机的服务体系。减少核心系统的复杂性，提高扩展性。
|
|
|
|
|
|
|
|
# 运维
|
|
|
|
## 现状
|
|
|
|
### 运行环境
|
|
|
|
目前两套运行环境：调试环境、生产环境。虽然试图隔离不同环境之间的调用，但是目前仍然存在不同环境互相调用的情况，存在很多风险。
|
|
|
|
### 发布服务
|
|
|
|
现在咱们的服务主要是运行在某一个虚拟机中（北京机房），边缘计算（生产视频拍摄）运行在树莓派里面，以后可能会迁移到华为云。北京机房的虚拟机数量50+，每发布一个服务，基本就要分配一个新的虚拟机，进行二级域名的代理的配置，目前比较依赖哈春宁进行统一的操作。
|
|
|
|
### 服务监控日志收集
|
|
|
|
目前没有服务监控，守护进程也需要自己配置。而且服务一般都是单节点单体服务。如果宕机可能造成整个系统不可用。应用日志目前也是存放在服务器上的某个文件夹中，没有做统一收集，对解决问题十分不利。
|
|
|
|
## 分析
|
|
|
|
通过现状分析主要存在以下问题：
|
|
|
|
1. 运维工作繁重，而且只有哈春宁一个人能操作。
|
|
|
|
1. 两套环境的地址不同，给维护带来很多风险。
|
|
|
|
1. 服务缺乏必要的监控和日志收集
|
|
|
|
1. 服务器资源无法更合理的使用（所有的虚拟机都有大量资源剩余）。
|
|
|
|
1. 无法实现HA。
|
|
|
|
|
|
|
|
## 思路
|
|
|
|
|
|
|
|
1. 使用k8s作为服务的运行环境，逐渐迁移现有服务到k8s集群中。k8s可以考虑用华为云提供的（可能费用比较高），逐步去掉原来50多台的虚拟机。
|
|
|
|
1. 利用k8s的四层代理，自动映射服务到子域名，k8s内部服务之间使用内部服务地址通讯，消除两套环境的差异。
|
|
|
|
1. 使用gitlab ci/cd把服务的提交验证、部署到两套环境做成自动化。
|
|
|
|
1. 在k8s中实现服务监控与日志收集。
|
|
|
|
|
|
|
|
通过以上步骤，服务都运行在k8s中，运维只要处理k8s，云提供商还能进一步简化操作，试稳定性大大提高，而且大大减运维工作量。
|
|
|
|
|
|
|
|
# 团队建设
|
|
|
|
|
|
|
|
## 现状
|
|
|
|
|
|
|
|
|
|
|
|
|
