This website requires JavaScript.

我在千寻的五个月(一)

2019.10.21 15:02 字数 3303 阅读 433 喜欢 5 评论 9

我于五月初入职千寻,开始写这篇文章时,时间间隔恰好五个月。时间不算长,本打算满六个月做一次小总结,无奈这几日心情着实不美丽,于是想通过记录过去五个月所学、所思来平静当下的心情。

今年五月份从 eBay 离职的时,我写了一篇 热血文章 ,说的是二十多岁的我不应该在工作中死去。时至今日,我感慨那时我的「鲁莽」选择,或是生活如此,在庞大的人群中,你不得不向前走。

Spark(eBay manager)经常问我,除了钱之外,我想从一份工作中获得什么?除了张口即来的人脉、成长,在生活的章节,我想谈谈,我在一份工作中,想得到什么?

学习总结

做为阿里系的公司,千寻位置在技术上,还是没让人失望。这里技术氛围比较浓厚,推崇讨论是解决问题的最好方案,只要你的方案够好,能说服大多数人,方案就可以被认可、实施。而且这是一家没有历史包袱的公司,很多事情都在建设当中,如 ci/cd,监控相关等。只有积极主动,总有可以学到的知识。

前端网关

前端网关的思考中 ,我曾画了一张简单的前端网关图:

前端网关

API GateWay 实际也就是 BFF 层,随着各种基础设施的完善,对这层也做了一些要求,除了需要做鉴权、判断是否登录外,还承载着整个链路监控(下文会讲到)的重要一环。当然,这也对调用接口方做了一定的要求,就比如我司,强制每个请求为 post,并且需要带 requestId,做为整个链路的 id,因此所有请求的格式基本如下:

// method: post
{
  "resuestId": "xxx",
  "param": "xx",       // 所有参数
  // 省略其他信息
}

配置中心

在一个后端工程中,通常在每个环境下,都需要不同的配置。比如一般的工程,有 development、production、test 环境,这些环境的配置文件肯定是不同的。当然,你可以通过在不同的环境下,加载不同的配置文件即可,比如 development.env、production.env、test.env。但是这样暴露了一系列问题:

  • 配置文件太多,维护成本过高,比如我们一个后端工程中,有 dail1、daily2、test1、test2 ...等环境。
  • 配置跟随源代码保存在代码库中,容易造成配置泄漏
  • 修改配置,需要重新提交代码,后发布

因此,我们需要配置中心来统一管理配置,把业务开发者从复杂以及繁琐的配置中解脱出来,只需专注于业务代码本身,从而能够显著提升开发以及运维效率。同时将配置和发布包解藕也进一步提升发布的成功率,并为运维的细力度管控、应急处理等提供强有力的支持。

disconf.png

一般来说,配置中心需要满足以下基本几点:

  • 支持多环境配置
  • 静态配置与动态配置
    • 静态配置:及时在启动项目之前,先把配置拉到本地,每次配置改变,需要重启项目
    • 动态配置:修改配置后,无需重启项目,即可生效
  • 客户端,用于拉取配置,可以是一个 API,也可以是其他,只要提供了此能力即可
  • 操作日志
  • 权限控制(可选)
  • 回滚方案(可选)
  • 比较好的容灾方案(可选)

国内开源有名的方案,如携程的 Apollo 及 360 的 Qconf,大都实现了以上功能,并且还有很多其他强大的功能。它们功能相对较多且使用复杂并不是我们想要的,于是,我公司从 0 搭建了一个配置中心。

搭建一个简单的配置中心,并不是一件难的事,一个后台管理 + Service + 客户端(暴露给应用获取配置的 API )即可。客户端(暴露给应用获取配置的 API )可以简单的是 http://xxx:8080?appname=xxx&env=xxx。...

关于容灾方案,即是在服务不可用,依然能运行。可以将文件写入缓存解决此问题。即是当有数据更新,并且成功时,写文件到缓存,如果有文件便更新。当服务不可用时,直接读取缓存文件。

ci/cd

CI: Continuous integration 持续集成,开发者尽量时时刻刻合并开发分支至主干分支。避免直到发布日才开始合并,掉入集成地狱。无论何时新分支集成至项目,持续集成可以自动化测试持续验证应用是否正常。

CD: Continuous delivery 持续交付就是讲我们的应用发布出去的过程。这个过程可以确保我们尽可能快的实现交付。这就意味着除了自动化测试,我们还需要有自动化的发布流,以及通过一个按键就可以随时随地实现应用的部署上线。

也有 CD: Continuous deployment 持续部署,通过这个方式,任何修改通过了所有已有的工作流就会直接和客户见面。没有人为干预(没有一键部署按钮),只有当一个修改在工作流中构建失败才能阻止它部署到产品线。

简单来说 CI/CD 是一种在开发阶段引入自动化快速向客户交付应用的方法。

有很多插件,可以辅助完成 CI/CD 的工作,比如配合 github,的 travis、circle、codecov 等,在最近,github 也已经自带了 CI/CD,且操作简单,相信在不久之后,给 github 项目加上 CI/CD 将会是一个很轻松的工作。如果你有兴趣,可以参考此项目 blog-service ,处理持续部署外,此项目包含了基本的 CI/CD 功能。

如果你想在公司内网的私有库中搭建 CI/CD,可能就需要了解以下 Jenkins 了,比如说我司的一个 CI/CD,其大概架构图如下所示(前端老大画的):

CI/CD

严格的来说,上述架构图,只有一个持续交互的环节,使用一个可控制的方式,将应用部署上线。在这个架构图里,底层还是用的 jenkins,只不过我司给它换了一套 UI。

持续交互主要有两部分,第一部分是部署前端应用(即静态文件),另一部分是部署 NodeJS 应用。前者其实是将打包出来的静态文件推送至文件服务器,然后配合设置 nginx 即可。NodeJS 应用是将 build 后的 docker image 推送至阿里云的 Image Registrym,然后结合 k8s 的 ingress 即可调用相应的接口。

一些术语:

  • k8s:全称 kubernetes,用于容器的编排和管理

  • ingress

通常境况下 service 和 pod 仅可在集群内部网络中通过 IP 地址访问,所有到达边界路由器的流量或被背弃或被转发到其他地方。

    internet
        |
  ------------
  [ Services ]

ingress 是授权入站连接到达集群服务的规则集合。

    internet
        |
   [ Ingress ]
   --|-----|--
   [ Services ]

简单的理解:配置了 ingress 之后,才能在外部访问到容器里面的 service/pod。


未完待续。

赞赏支持

微信

支付宝

相关推荐

暂无推荐文章