微服务化后的按需精细化资源控制初探微服务化后的按需精细化资源

微服务化后的按需精细化资源控制初探 Martin Fowler 在2014年3月的文章中提到:

微服务是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。

国内实践微服务的先行者王磊先生也在《微服务架构与实践》一书中进行了全面论述。
微服务架构天然具备了弹性的优点，本文就介绍了作者初探微服务化后的 Company 按需进行精细化资源控制的过程和结果。

安装K8S监控Heapster
为使K8S具备弹性伸缩能力，需在K8S中安装监控器Heapster和Grafana，笔者踩了坑后更新的heapster的脚本已归档在github上，可直接获取，根据实际环境调整heapster中的 apiserver 这个参数后，如下启动：

git clone https://github.com/zenlinTechnofreak/LinuxCon-Beijing-WorkShop/tree/autoscal/kubernetesbash kube.sh
cd kubernetes/heapster/deploy
bash kube.sh

此后直接网页访问Grafana即可看到当前集群的资源现状，如下图：

文章图片

启动Company并加压
启动资源受限的Company应用并使其具备弹性伸缩能力（即HPA）：

git clone https://github.com/ServiceComb/ServiceComb-Company-WorkShop.git cd LinuxCon-Beijing-WorkShop/kubernetes/ bash start-autoscale.sh

启动的Company被限定每个pod的副本数弹性伸缩时控制在1到10之间，每个pod的cpu占用率小于50%，每个pod的的平均cpu占用率会被HPA通过弹性伸缩能力控制在100mcore以内。
查询初始HPA状态：

kubectl get hpa

文章图片

可以看到，在还没加压时，K8S默认给各微服务创建了一个pod，并且当前的资源限定情况也都可以看到。

export $HOST=: bash LinuxCon-Beijing-WorkShop/kubernetes/stress-test.sh

该脚本不断循环执行，大约 1s内向Company应用请求计算 fibonacci 数值200次（只是估数，毕竟通过msleep无法做到精确控制TPS），对Company造成请求压力。
加压后，可以看到结果：

文章图片

文章图片

结果
本文介绍了微服务改造后，对Company应用进行按需精细化控制，这相比传统单体架构来说，将大大帮助准确地化解应用瓶颈，提高资源利用效率。

请点击左下角阅读原文阅读详细步骤。

PS：在ServiceComb官方网站上，还用心良苦地提供了博文介绍如何使用Jmeter和Grafana进行性能压力测试，请访问：
http://servicecomb.io/docs/stress-test-on-company-with-jmeter-in-k8s/
【微服务化后的按需精细化资源控制初探】