昨天，腾讯云正式加入CNCF和Linux基金会，不仅希望在国际开源圈进一步发声、扩大腾讯云在技术领域和开源领域的影响力，同时也意味着将承担更多的责任，我们将从产品出发，基于大量用户在产品使用中的感受，以及腾讯云的服务实践，将有价值的特性推送和反馈给社区，与社区一起完善相关特性，同时我们从社区中获得广泛的用户反馈，再次回到产品。 在这样的互动中，我们从社区中来，到用户中去，目前在CNCF的技术领域，华尔街见闻已经用上我们的容器服务，华尔街见闻的技术团队亲自撰稿向业界分享真实的实践经验，经华尔街见闻的授权，我们将这个实践分享给大家： 简 介 华尔街见闻的运营方上海阿牛信息科技有限公司是全球金融信息服务提供商，每天全平台为近200万用户提供资讯、数据、研究等服务。旗舰产品华尔街见闻APP长期位居各应用市场财经资讯类客户端第1位。由于将重大事件、市场的基本面变化和100多种全球资产价格紧密关联，在金融领域具有极高渗透率。首创的7x24快讯模式已经成为在中文世界理解全球市场的最快来源。也因此，该产品有技术架构复杂，需要高并发承载能力等特性。
背 景
原先的系统是PHP monolithic架构，功能按模块划分，日积月累，最后模块达到60 个，新人接手项目会拿到一整个系统的代码，以及需要整个系统的配置，而他可能只需要专注开发不到1/10的业务。
我们的主要业务是即时资讯，资讯具有时效性，网站的访问量会呈现锯齿形分布。当遇到特大新闻如英国退欧、美国大选、法国大选等，我们要能弹性地通过增加服务资源，提高服务的容量。
我们希望一个低优先级服务出现问题之后，不影响主要服务；一个主要服务能保证更高的可用性，就算出现问题，也要保证优雅降级。
PHP单体应用在生产环境服务的时候，所有业务都跑在一个程序里，增加了系统的脆弱性，一个隐藏的性能问题，能在服务量激增的时候成为压垮骆驼的一根稻草。
由于架构落后于需要，我们不得不用硬件弥补性能上的问题，导致云服务器成本不断增加。
由于没有方便的监控和运维工具，导致排查问题的效率低，使得在系统遇到问题的时候排查困难，耗时过长。
开发新任务的同时，我们需要修复原有系统的性能问题。
▲PHP monolithic架构图
因此，在2016年11月至2017年3月，我们采用微服务架构启动重构，尝试解决一部分上述问题，在伸缩性上能以服务为单位进行拓容，同时，这一设计会在某些方面增大我们的开发成本和运维成本。
很显然，以前在单体应用中能直接登录服务器，查看出错日志，现在错误散落在不同的服务中，为我们的错误排查带来了困难。
如何把服务的日志收集并分析。
每个服务有互相独立的MySQL、Redis，公共服务方面需要高可用的服务发现，调用链路分析，日志收集储存设施等。
▲微服务架构图
每台服务器上均衡地部署服务，LB接受用户的请求，将请求转发到API gateway，API gateway向服务发现查询具体服务的IP和端口，服务执行完业务逻辑后向上返回数据。 我们选择golang作为我们的后端开发语言。
拆分的原则是通过服务功能划分，尽量避免双向依赖。我们拆分出了13个服务，包括用户、内容、实时新闻、评论、搜索、商城、支付、三方代理等服务。 服务间使用protobuf协议对数据进行编码，使用UDP作为传输协议。 Etcd搭建多节点高可用的服务发现。 我们选择Hystrix作为服务保护以及服务降级的方案。 我们选择了Kubernetes。
这是我们最先选择的方案，因为Docker 1.12之后已经将Swarm功能集成到Docker Engine，能以最少的配置启动Docker集群。经过简化和设计的控制台API，方便地管理集群、调整服务如控制服务的数量、CPU、内存限制等。往集群内加入机器非常简单，只需要运行一条命令即可。使用manager-worker架构，manager作为调度节点，支持高可用。
这是谷歌主导的服务编排工具，它支持Docker，相比Docker Swarm来说，它的概念更多，分层更细。功能方面多于Docker Swarm，支持一些高级功能如秘钥管理、配置管理、自动拓容等。在生产环境的应用比较广泛，稳定性更高。
裸机部署是我们的一个备案，考虑到以上两个方案在当时没有具体线上实施的经验，所以如果Docker Swarm和Kubernetes都没有成功，我们直接裸机部署。 由于之前使用github开发人员的代码提交在有翻墙工具的帮助下速度依然不是很理想，我们自建了Gitlab仓库，自此开发过上了幸福的生活。 swarm和kubernetes是基于docker快速创建删除服务，通过增加容器为服务拓容，缩减容器为服务缩小规模，所以所有项目必须要构建docker镜像。按项目类型划分，我们遇到3种镜像打包情况。
后端服务90%是golang项目，针对golang的镜像，我们采取将golang项目编译成可执行文件，基于最小的alpine镜像打包入docker，这里遇到过一个问题，就是alpine里缺少openssl的证书，无法支持https，我们自定义了新的基础镜像，不仅将证书文件打入镜像，同时为了线上调试方便，增加了tcpdump、strace、bash等工具，在初期调试容器间通信问题时发挥重要的作用。
见闻的后台以及m站基于Vue，编译后生成的静态文件打入镜像，通过nginx访问。为了支持HTTP2，我们打入nginx镜像缺少的证书。
主站PC站基于nodejs、Vue实现服务端渲染，所以不仅需要依赖nodejs，而且需要利用pm2进行nodejs生命周期的管理。为了加速线上镜像构建的速度，我们利用taobao源https://registry.npm.taobao.org进行加速, 并且将一些常见的npm依赖打入了基础镜像，避免每次都需要重新下载，镜像打包从开始的3分钟缩减到1.5分钟。
▲三类镜像结构
我们利用Gitlab CI配置了测试、镜像构建、镜像发布、自动部署等流程，后端服务从提交代码到测试分支到测试环境自动部署完成花费1.5分钟，前端服务平均为2.5分钟。
▲CI任务中的test- |
|
声明：文章版权归原作者所有 部分文章转自互联网 如有侵权请联系
[邮箱地址] 删除
|
注册
登录
