Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in
  • W wiki
  • Project information
    • Project information
    • Activity
    • Labels
    • Planning hierarchy
    • Members
  • Issues 0
    • Issues 0
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
  • Monitor
    • Monitor
    • Incidents
  • Packages & Registries
    • Packages & Registries
    • Package Registry
    • Infrastructure Registry
  • Analytics
    • Analytics
    • Value stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Create a new issue
  • Jobs
  • Issue Boards
Collapse sidebar
  • public group
  • wiki
  • Wiki
  • plan

Last edited by 陈志国 Mar 08, 2021
Page history
This is an old version of this page. You can view the most recent version or browse the history.

plan

  • 开发
    • 现状
      • 核心系统
      • 附属系统
    • 分析
    • 思路
  • 运维
    • 现状
      • 运行环境
      • 发布服务
      • 服务监控日志收集
    • 分析
    • 思路
  • 团队建设
    • 现状

开发

现状

核心系统

现状咱们有一套主流程相关的系统,主要包括赛事系统(主机)、运动超市(小程序)、产销后台、产销接口、定制发货、仓库管理等。

附属系统

主要包括CRM、账号系统、同步程序、生产拍照、3D设计工具、2D设计工具等等。

分析

虽然现有各个系统存在着很多设计不良的问题,或者使用上的不方便的地方,但是也还是可以完成主体的流程。所以未来需要不断增强和完善核心系统的功能。而附属系统会越来越多,而且会更深度的与核心系统集成。所以有如下要求:

  1. 核心系统不断完善和增强
  2. 核心系统需要比较容易扩展
  3. 附属系统需要快速搭建
  4. 附属系统与核心系统持续集成

思路

为了应对这些变化,我觉得开发团队方面,我觉得一定要集中优势力量,采取小步快跑的策略。主要是以下方面:

  1. 开发人员集中起来,所有人理解所有要做的业务,然后共同来完成设计和编码。
  2. 做新功能,在现有系统的基础上。
  3. 在做新功能的时候,不断优化原有的设计,比如把一些数据库表从主库中剥离。
  4. 充分利用事件(mq)进行解耦。把服务间的耦合度降低。
  5. 逐渐把核心系统与辅助系统融合起来(不是变成一个大单体服务),比如实现统一登录、增加门户等,避免碎片化。
  6. 逐渐把核心系统拆分出更多的外围服务,形成有机的服务体系。减少核心系统的复杂性,提高扩展性。

运维

现状

运行环境

目前两套运行环境:调试环境、生产环境。虽然试图隔离不同环境之间的调用,但是目前仍然存在不同环境互相调用的情况,存在很多风险。

发布服务

现在咱们的服务主要是运行在某一个虚拟机中(北京机房),边缘计算(生产视频拍摄)运行在树莓派里面,以后可能会迁移到华为云。北京机房的虚拟机数量50+,每发布一个服务,基本就要分配一个新的虚拟机,进行二级域名的代理的配置,目前比较依赖哈春宁进行统一的操作。

服务监控日志收集

目前没有服务监控,守护进程也需要自己配置。而且服务一般都是单节点单体服务。如果宕机可能造成整个系统不可用。应用日志目前也是存放在服务器上的某个文件夹中,没有做统一收集,对解决问题十分不利。

分析

通过现状分析主要存在以下问题:

  1. 运维工作繁重,而且只有哈春宁一个人能操作。
  2. 两套环境的地址不同,给维护带来很多风险。
  3. 服务缺乏必要的监控和日志收集
  4. 服务器资源无法更合理的使用(所有的虚拟机都有大量资源剩余)。
  5. 无法实现HA。

思路

  1. 使用k8s作为服务的运行环境,逐渐迁移现有服务到k8s集群中。k8s可以考虑用华为云提供的(可能费用比较高),逐步去掉原来50多台的虚拟机。
  2. 利用k8s的四层代理,自动映射服务到子域名,k8s内部服务之间使用内部服务地址通讯,消除两套环境的差异。
  3. 使用gitlab ci/cd把服务的提交验证、部署到两套环境做成自动化。
  4. 在k8s中实现服务监控与日志收集。

通过以上步骤,服务都运行在k8s中,运维只要处理k8s,云提供商还能进一步简化操作,试稳定性大大提高,而且大大减运维工作量。

团队建设

现状

Clone repository
  • Home
  • plan
  • training record
  • training