持续交付优化之路(一)产品剖析

本文用于记录一个人肉运维的奋起之路

系统层面

系统组件:

    1、nginx(单点或负载)

    2、memcached(只能单点)

    3、rabbitmq(单点)

    4、php

    5、mysql(主从)

    6、mongodb(主从)

    7、redis(主从)

wKioL1nDUJeRBAa1AABKzaoeWRE877.png-wh_50

架构:

    1、从应用服务器没有任何意义

    2、缺乏高可用可靠性

wKioL1nDUHzgO0h-AAEVKLsFbtk141.png-wh_50




产品层面

服务特点:

    1、微服务

    2、容器不同(jetty、netty、paly)

    3、配置文件繁杂不易管理

更新方式:

    1、jar包,war包,配置文件,sql脚本,移动端分开更新,容易出问题

    2、容易因更新导致服务异常

分支特点:

    开发只有一个主分支(release),每次定小版本便会将当前的主分支克隆一份并命名a.b,后面再次发版则又克隆一份最新的release命名为a.b+1或者a+1.0 。这会导致有些环境部署的时候用的release主分支,但过了很久之后需要重新构建移动端会构建最新的release导致新端连旧后台,出一堆问题。


痛点

没有高可用

服务较多管理不便(没有管理平台)

分支管理是个坑


努力方向

1、要想实现高可用,必须先实现监控和管理平台

2、完成监控和管理平台后加入keepalive实现高可用

3、分支策略:release分支只用来bugfix和验证新功能,作为线上测试环境使用,用户部署和每次发版都是用固定的版本名。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章