(背景:我目前所在一家互联网公司,负责技术方面的事情。为了让大家看懂此文,有必要介绍一下我们公司的背景。我们公司的主要产品,是一个汽车电商相关产品,涉及到C端用户,B端经销商,集团,ToB销售等多个角色。订单状态众多,业务流程复杂。我们的产品规模,忙时:DAU 20K,Mysql CRUD 2000W q/d)
[TOC] <---- 为嘛简书不支持这个……
人们总是这样,到了年底的时候,才会想起时间。
回想这一年,虽忙的琐碎,却也充满收获,这真让人感到欣慰。
自打接手公司技术坑之日起,“保障服务可用,梳理研发流程,提升团队技术栈”,便是给自己制定的一个小目标。于是这一年尤其是后半年,“坚持,亢奋,努力”便是整个团队工作状态的真实写照。
就像所有技术团队一样,没有什么努力,会被白白浪费。回头看,那些经历,那些挑战,都值得被纪念。
持续集成(Topka-CI)
说起我们的产品线,客户端有“TopDeals”、“TopSales”、“AK47”,三款App。每款App分别有iOS和Android两个版本。当时客户端这边有10名同学,每月每款App大约迭代1至2个版本,这样的迭代速度不可谓慢。而就在这样的速度之下,app打包的工作还要人工完成,发布时,Android十几个渠道包一打就是大半天。即便在测试过程中,daily build也要工程师们手动完成。这极大影响了工作效率。而且手工打包,往往还会出现更多意想不到的问题——手滑弄错了配置项之类……
在这样的背景下,TopkaCI应运而生。
TopkaCI 主要完成以下实现以下功能:
- 支持Android、iOS、ionic等平台项目的自动打包
- 按照预定规则,从代码库的预定分支自动拉取代码
- 支持mvn,gradle,npm,cocoapod以及bower的依赖管理,根据依赖定义及源信息来决定是否更新依赖
- 对Android及iOS代码进行lint检查
- 编译代码
- 对编译后的App进行UI层面的自动化测试(使用两个平台的原生测试工具——UIAutomator与UIAutomation)
- 成果物管理:App编译后,生成安装二维码,实现测试人员用手机扫描二维码自动将App安装到手机的功能
- 成果物管理:iOS App自动上传到iTunesConnect并发出TestFlight邮件,通知相关人员测试
- 成果物管理:每次打包结果根据版本自动上传到TopkaRepo,更新资产库
TopkaCI在开发过程中,遇到了很多坑——几乎每一个环节都有技术问题需要解决。这些困难主要包括了以下几个方面:
- 对CI服务的扩展开发
- 对编译过程所涉及到的相关工具的钩子进行开发,让CI过程按照上述流程连通起来
- 原有项目的配置管理方式过于手工化,需要改造
虽然TopkaCI遇到了一些困难,但在TopkaCI在上线之后,大家用起来还是很爽的。持续集成极大提高了团队的研发效率,现在研发团队各项目的打包过程完全自动化,“原打包架构师就此转岗,去承担更为重要和艰巨的任务”。哈哈。
ci-1.pngMySQL 高可用改造
话说有一天,收到这样一封报警邮件,顿时惊呆了。
db-1.png其实,我们并不是第一次收到这样的邮件。而对云服务的可用性来说,9999的概念是,每1万天,这样的邮件至多只能收到一次。但是很显然,他们并没有做到。
尽管可以向服务商提工单,但我还是不相信这样的问题会得到妥善解决。我也不想陷入无休止的拉锯战中,于是我们决定自己解决。
对MySQL的高可用,我们有如下需求:
- 集群内的多个数据库实例实现热切换,当有服务失败时,自动切换到另一实例。
- 迁移过程中保证数据的一致性以及事务的可用性
- 迁移后,当发现down掉的服务恢复时,自动恢复数据,保证集群同步
- 读写分离,当集群内的可用实例数量>=2时,自动分配1读1写。
- 应用无感,无需为对应数据库的高可用需求做任何修改。
好了,既然有了需求,就来分析一下怎么实现。
高可用的核心需求,是故障迁移——即当系统出现故障时,能够自动将服务切换至可用服务。遗憾的是,MySQL本身并没有提供这样的failover方案,不过像这样的轮子肯定是有人造过的了,但是如何选择轮子,还需要费一番功夫。除了满足上述需求以外,我们还希望框架尽可能的做到:
- 方案成熟
- 开源,可扩展
MySQL的高可用,目前来看主要基于以下几种技术:
- 主从复制技术
- Galera
- NDB
- 中间件及代理
- 共享存储
- 主机高可用
最终根据自身情况,我们选择了相对成熟的MHA方案做为我们的高可用方案。MHA能实现之前提到的除了读写分离之外的大部分需求,并可以保证数据的一致性。而读写分离,我们使用keepalived来解决。目前上线几个月,效果令人满意。
微服务
微服务这个事,近年挺火,但很遗憾,我们微不起来。
这里既有历史原因,又有历史原因。说来说去,都是历史原因。但是,任何一家互联网公司,经过这么多年产品的成长与迭代,除非具备了推倒重来的勇气,否则各种“历史原因”都会存在。
但让我决定要做这样一件事的原因,是因为这样一张图。
tm1.png是的,你没看错,纵轴单位是秒,这着实让人崩溃。看到这张图的第一感觉,是我们的程序有问题,于是:
- 赶紧翻代码,然而从代码上看,没什么大事
- 翻慢查询日志,涉及到这个接口的sql全都查一遍,看看慢查询是否存在
- 优化慢查询sql
- 优化相关代码的实现逻辑,看看能不能用缓存什么的
折腾了半天,No luck!接着我继续看上面这张图,这张图很有意思,7秒、14秒来回蹦,7秒发生在白天,14秒发生在晚上……等等,我似乎搞清楚怎么一回事了。
排查所有定时任务,尤其是晚上执行的。确定这些任务在执行时,整个系统哪里存在压力风险……结果我找到了我们系统中一些非常重要定时任务,这些任务在运行过程中,极大的占用了网络带宽,以及数据库资源。
行了,拆吧。
拆库,拆代码,构建服务。更为重要的是,要让这个新服务的执行过程与线上服务完全分离。也就是说,新服务完全不占用线上环境的资源,我们为它搭建独立的内网环境以及公网IP。而这个服务与线上服务的交互,则通过IPSec隧道来打通。
m1.png m2.png至此,问题解决。而且所有接口的响应速度都有了极大提高。爽!
ELK
ELK,我们很早就有了。但是ELK如果想真正用起来,其实还是要解决很多问题的。
让我下定决心把ELK用起来的关键事件,是某次参加一个技术会议,听了“小红书”运营总监的一个分享……
先来说需求。我们的ELK目前只打算记录一件事——nginx访问日志。但为了让记录的日志发挥最大的效能,我们需要将日志结构化。具体说来,有以下几个方面的需求:
- 结构化nginx日志,常规的日志字段结构化
- 结构化通用业务信息,如:访问机型、app版本、token等
- 保存非文件类型的http response_body
- nginx日志记录率达到100%,结构化过程中不能出现任何异常导致数据丢失
具体部署方式,其实也都比较简单。我们做了下面几个事情算是比较独特吧:
- 写了一个 nginx lua script 来把response body搞出来
- 为了分摊压力,我们采用了由3台机器组成的kafka集群做为消息队列,并用一台机器做为logstash客户端去专门消费kafka队列中的数据,而ElasticSearch也使用3台机器实现集群部署(后来证明此架构被过度设计了)
- 在logstash消费过程中,写了一些ruby script来结构化nginx日志以及通用业务信息
- 保证记录率,其实是之前踩到的一个坑。ElasticSearch自动映射类型有些不准,偶尔会出现冲突。出现冲突之后,再进来的数据就会exception
上线之后,ELK向运营及技术团队开放。大家在kibana中查一查日志、做一些数据可视化什么的,用起来还都比较Happy。不过有一个点,在我心里一直有个疑问。
这套系统,总共开了7台机器。呃呃呃。我们抓4台web服务器的日志要开7台机器呀,这样真的科学么?
观察了一下这七台服务器的负载,我的天啊,低得可怜。那就,合并吧。
于是,我们使用Docker,将以上服务不同的Docker镜像跑在一台机器上,并且将这些服务的数据做为不同的挂载盘挂载到host系统。运行起来一切正常!硬件利用率大增,成本大省,哈哈。
并发与弹性计算
2016,不提到并发与弹性计算都不好意思说自己设计过什么架构。
之前提到,我们在忙时,DAU 20K左右。但任何互联网服务,都有忙闲,忙时与闲时,对服务器的负载压力必然不同。如果说云端计算能力对互联网服务来说是一种资源,那无论何时都开着同样数量的服务器,保持着一成不变的系统架构的做法,就好像家里无论何时都开着自来水一样——这不是钱不钱的问题,而是傻不傻的问题。正因如此,本着smart & geek的作风,我们怎能忍受自家的自来水成天开着。
“用最适当的成本支撑目前的业务,并有能力应对用户暴涨的情形”是这套系统设计的初衷及核心思想。
我们的线上系统按照PaaS层来分,大致可以分为负载均衡、缓存、静态文件、CDN、Web服务、日志服务、流式计算、消息队列,关系型数据库,非关系型数据库等多种服务,其中大部分服务为集群服务,线上系统大约有几十台机器的规模,我们首先需要实现对Web集群服务的弹性计算。
那么,这件事情的需求其实是这样的:
- web服务器无状态化(这个在之前已经基本实现)
- 通过对web服务器四种核心能力——CPU、内存、磁盘IO、网络负载的使用率监测,决定是否需要减少机器数量或开启新的机器
- 开启新的机器需要一个初始化代码库、配置文件、服务可用性检测的过程
- 关闭机器前,开启机器后,需要自动修改负载均衡策略来引导流量
- 通过云服务商的API进行数据监测及弹性部署
- 支持根据业务需要自定义弹性策略:如我们每天可能会在同一时间向部分用户发送推送,届时部分服务的流量可能会增大。所以我们需要能自定义弹性策略,做到提前部署
这个项目现在还没有最终完成。而未来,除了Web服务,我们也会考虑实现其他服务的弹性计算方案。届时除了节约成本,对运维团队的自动化运维的能力,也将是很大的提升。
生产环境的Docker
生产环境的Docker,我目前持谨慎态度,尽管京东在这两年618大促在生产环节上大量使用Docker。
Docker目前最大的痛点,在于集群化。生产环境使用Docker,只要牵扯到集群,你就得考虑太多问题:镜像管理、容器管理、编排……虽然现在有mesos,但是个人认为现在docker生态与集群相关的轮子还不足够好,自己造轮子得不偿失,依然得谨慎。
但Docker我们确实是用了的,没用在生产环境,却用在测试、测试的日志等重要度其次且暂时没有集群需求的环境。在这些场景中,用起来还是很赞的。
Mock与全栈
互联网产品,即便是渡过了从0到1时期的产品,其迭代速度也是惊人的。传统软件工程学所谓的瀑布流的软件开发模式,早已无法适应互联产品的研发迭代速度。且不说瀑布流,哪怕是敏捷,又有多少团队能够真正做到“在对的时间兑现你的承诺”。
“设计等待产品,接口等待产品,客户端等待接口,客户端等待设计……”
这些等待,有太多我不能理解。按照我的想法,产品只要有了概要定义,所有人都可以开始干活。因为软件开发中的任何一项工作,无论是产品定义、界面设计、接口实现、客户端实现,都必然要经历一个“从构建到精化”的过程,这个过程的起点,并不必要有上一环节的非常详细的输入才可以开始。
道理是这个道理,但有些事情一旦成为了习惯,就很难解决。三十来人的研发团队,习惯已经养成,怎么掰,确实是个问题。
想让技术团队有所改变,必须要引入新的技术。于是,我决定引入mock。先把“客户端等待接口”这个事情给掰过来!
mock这个东西,对于客户端团队来说,是欢迎的。因为客户端同学可以更早拿到可以运行的API接口,可以更早的开始开发。对完成kpi更有益处。
而对于服务端团队,就得说服他们能在实现接口之前,先做接口设计,并形成mock文档。这样会增加他们的工作量。但说服他们其实也有足够的理由——有了mock之后,没人催着你“快点出接口”,接口可以和客户端同步开发,最后留几天联调即可,其实跟之前相比不用那么紧张了。
对于mock server的需求,我们有如下几点:
- 开源,免费,协议友好,支持二开
- 有UI——这一点非常重要
- 支持LDAP
最后,我们选用了阿里的RAP……RAP在阿里据说超多团队在用,但其实它的代码写的非常差,bug很多,更有诸如”太复杂的json结构保存容易出错”这样的恶性bug。但mock server,现在开源项目不太多,选RAP实属无奈。
等到了下半年,产品需求呈发散态势,多条业务线齐头并进。但各个端的研发需求量却不均衡,经常出现某个月App这边需求很少,但后台、经销商平台需求爆棚的情况。于是,我开始组织App团队学习服务端开发,利用培训、技术沙龙及code review等手段,鼓励(bi)(zhe)大家承担一些服务端、前端的开发任务。虽然起初很累,但现在大家已经基本实现自己写自己的接口、app。而为了保险起见,比较深的逻辑及模型的建立,目前还是由资深的服务端同学完成。
结合mock与全栈,对比之前,现在整个团队的研发效率上了一个大台阶。配合更为细化和有针对的敏捷流程,一个充满战斗力和承诺精神的研发团队已经基本建立。
写到这里,我不禁想到一个问题——“究竟什么才是技术领导力?”
“通过智慧的想法和技术的手段,让组织及研发团队都能坚信我们有能力兑现承诺。”在我看来,这就是技术领导力的最好体现吧。
PS:这一年参加了不少技术会议,全部都是开发向。所有跟技术领导力有关的,我一概没有参加。
不是总结的总结
回忆总是让人充满希望。上面说提到的这些项目,每一个其实都有继续做下去的意义。而2016对于我们来说,是打基础的一年,我们希望能够利用这一年,为组织在技术方面构件一套坚实、适用而又充满无限可能的技术栈,来应对可能到来的高流量及业务膨胀。现在看来,这个目标基本算是实现了。
而从个人角度说,在2016工作方面值得纪念的却远不止这些,这里仅记录了一些与业务无关的方面。所以说到收获,也不仅于此吧。
但是,遗憾也还是有的。最遗憾的就是React Native在移动端团队没有应用起来,那么未来的一年,为今年的小遗憾定个小目标:希望能够改组前端团队为“大前端团队”,React Native/JS用起来~
希望新的一年团队能更加给力,自己能成长更多。
网友评论