网站个人备案做企业网站,aspnet网站开发书,中国大搞建设,wordpress问答悬赏功能作者 | 徐鹏责编 | 刘静出品 | CSDN(ID#xff1a;CSDNnews)我们的产品是Linkflow#xff0c;企业运营人员使用的客户数据平台(CDP)。产品的一个重要部分类似企业版的”捷径”#xff0c;让运营人员可以像搭乐高积木一样创建企业的自动化流程#xff0c;无需编程即可让数据…作者 | 徐鹏责编 | 刘静出品 | CSDN(IDCSDNnews)我们的产品是Linkflow企业运营人员使用的客户数据平台(CDP)。产品的一个重要部分类似企业版的”捷径”让运营人员可以像搭乐高积木一样创建企业的自动化流程无需编程即可让数据流动起来。从这一点上我们的业务特点就是聚少成多把一个个服务连接起来就成了数据的海洋。理念上跟微服务一致一个个独立的小服务最终实现大功能。当然我们一开始也没有使用微服务当业务还未成型就开始考虑架构那么就是”过度设计”。另一方面需要考虑的因素就是”人”有没有经历过微服务项目的人团队是否有devops文化等等综合考量是否需要微服务化。要不要微服务微服务的好处是什么相比于单体应用每个服务的复杂度会下降特别是数据层面(数据表关系)更清晰不会一个应用上百张表新员工上手快对于稳定的核心业务可以单独成为一个服务降低该服务的发布频率也减少测试人员压力可以将不同密集型的服务搭配着放到物理机上或者单独对某个服务进行扩容实现硬件资源的充分利用部署灵活在私有化项目中如果客户有不需要的业务那么对应的微服务就不需要部署节省硬件成本就像上文提到的乐高积木理念。微服务有什么挑战一旦设计不合理交叉调用相互依赖频繁就会出现牵一发动全身的局面。想象单个应用内service层依赖复杂的场面就明白了项目多了轮子需求也会变多需要有人专注公共代码的开发开发过程的质量需要通过持续集成(CI)严格把控提高自动化测试的比例因为往往一个接口改动会涉及多个项目光靠人工测试很难覆盖所有情况发布过程会变得复杂因为微服务要发挥全部能力需要容器化的加持容器编排就是最大的挑战线上运维当系统出现问题需要快速定位到某个机器节点或具体服务监控和链路日志分析都必不可少。下面详细说说我们是怎么应对这些挑战的开发过程的挑战持续集成通过CI将开发过程规范化串联自动化测试和人工Review我们使用Gerrit作为代码分支管理工具在流程管理上遵循Gitlab的工作流模型开发人员提交代码至Gerrit的magic分支代码Review人员Review代码并给出评分对应Repo的Jenkins job监听分支上的变动触发Build job。经过IT和Sonar的静态代码检查给出评分Review和Verify皆通过之后相应Repo的负责人将代码merge到真实分支上若有一项不通过代码修改后重复过程Gerrit将代码实时同步备份至的两个远程仓库中。集成测试一般来说代码自动执行的都是单元测试(Unit Test)即不依赖任何资源(数据库消息队列)和其他服务只测试本系统的代码逻辑。但这种测试需要mock的部分非常多一是写起来复杂二是代码重构起来跟着改的测试用例也非常多显得不够敏捷。而且一旦要求开发团队要达到某个覆盖率就会出现很多造假的情况。所以我们选择主要针对API进行测试即针对controller层的测试。另外对于一些公共组件如分布式锁json序列化模块也会有对应的测试代码覆盖。测试代码在运行时会采用一个随机端口拉起项目并通过http client对本地API发起请求测试只会对外部服务做mock数据库的读写消息队列的消费等都是真实操作相当于把Jmeter的事情在Java层面完成一部分。Spring Boot项目可以很容易的启动这样一个测试环境代码如下RunWith(SpringRunner.class)SpringBootTest(webEnvironment SpringBootTest.WebEnvironment.RANDOM_PORT)测试过程的http client推荐使用io.rest-assured:rest-assured支持JsonPath十分好用。测试时需要注意的一个点是测试数据的构造和清理。构造又分为schema的创建和测试数据的创建。schema由flyway处理在启用测试环境前先删除所有表再进行表的创建测试数据可以通过Sql读取一个sql文件进行创建在一个用例结束后再清除这些数据。顺带说一下基于flyway的schema upgrade功能我们封成了独立的项目每个微服务都有自己的upgrade项目好处一是支持command-line模式可以细粒度的控制升级版本二是也可以支持分库分表以后的schema操作。upgrade项目也会被制作成docker image提交到docker hub。测试在每次提交代码后都会执行Jenkins监听gerrit的提交通过docker run -rm {upgrade项目的image}先执行一次schema upgrade然后gradle test执行测试。最终会生成测试报告和覆盖率报告覆盖率报告采用jacoco的gradle插件生成。如图这里多提一点除了集成测试服务之间的接口要保证兼容实际上还需要一种consumer-driven testing tool就是说接口消费端先写接口测试用例然后发布到一个公共区域接口提供方发布接口时也会执行这个公共区域的用例一旦测试失败表示接口出现了不兼容的情况。比较推荐大家使用Pact或是Spring Cloud Contact。我们目前的契约基于”人的信任“毕竟服务端开发者还不多所以没有必要使用这样一套工具。集成测试的同时还会进行静态代码检查我们用的是sonar当所有检查通过后jenkins会1分再由reviewer进行代码review。自动化测试单独拿自动化测试出来说就是因为它是质量保证的非常重要的一环上文能在CI中执行的测试都是针对单个微服务的那么当所有服务(包括前端页面)都在一起工作的时候是否会出现问题就需要一个更接近线上的环境来进行测试了。在自动化测试环节我们结合Docker提高一定的工作效率并提高测试运行时环境的一致性以及可移植性。在准备好基础的Pyhton镜像以及Webdriver(selenium)之后我们的自动化测试工作主要由以下主要步骤组成测试人员在本地调试测试代码并提交至GerritJenkins进行测试运行时环境的镜像制作主要将引用的各种组件和库打包进一个Python的基础镜像通过Jenkins定时或手动触发调用环境部署的job将专用的自动化测试环境更新然后拉取自动化测试代码启动一次性的自动化测试运行时环境的Docker容器将代码和测试报告的路径镜像至容器内自动化测试过程将在容器内进行测试完成之后不必手动清理产生的各种多余内容直接在Jenkins上查看发布出来的测试结果与趋势。关于部分性能测试的执行我们同样也将其集成到Jenkins中在可以直观的通过一些结果数值来观察版本性能变化情况的回归测试和基础场景将会很大程度的提高效率、便捷的观察趋势。测试人员在本地调试测试代码并提交至Gerrit通过Jenkins定时或手动触发调用环境部署的job将专用的性能测试环境更新以及可能的Mock Server更新拉取最新的性能测试代码通过Jenkins的性能测试插件来调用测试脚本测试完成之后直接在Jenkins上查看通过插件发布出来的测试结果与趋势。发布过程的挑战上面提到微服务一定需要结合容器化才能发挥全部优势容器化就意味线上有一套容器编排平台。我们目前采用是Redhat的Openshift。所以发布过程较原来只是启动jar包相比要复杂的多需要结合容器编排平台的特点找到合适的方法。镜像准备公司开发基于gitlab的工作流程git分支为masterpre-production和prodution三个分支同时生产版本发布都打上对应的tag。每个项目代码里面都包含dockerfile与jenkinsfile通过jenkins的多分支pipeline来打包docker镜像并推送到harbor私库上。docker镜像的命令方式为 项目名/分支名:git_commit_id如 funnel/production:4ee0b052fd8bd3c4f253b5c2777657424fccfbc9tag版本的docker镜像命名为 项目名/release:tag名如 funnel/release:18.10.R1在jenkins中执行build docker image job时会在每次pull代码之后调用harbor的api来判断此版本的docker image是否已经存在如果存在就不执行后续编译打包的stage。在jenkins的发布任务中会调用打包job避免了重复打包镜像这样就大大的加快了发布速度。数据库Schema升级数据库的升级用的是flyway打包成docker镜像后在openshift中创建job去执行数据库升级。job可以用最简单的命令行的方式去创建oc run upgrade-foo --imageupgrade/production --replicas1 --restartOnFailure --command -- java -jar -Dprofileproduction /app/upgrade-foo.jar脚本升级任务也集成在jenkins中。容器发布openshift有个特别概念叫DeploymentConfig原生k8s Deployment与之相似但openshift的DeploymentConfig功能更多些。Deploymentconfig关联了一个叫做ImageStreamTag的东西而这个ImagesStreamTag和实际的镜像地址做关联当ImageStreamTag关联的镜像地址发生了变更就会触发相应的DeploymentConfig重新部署。我们发布是使用了jenkinsopenshift插件只需要将项目对应的ImageStreamTag指向到新生成的镜像上就触发了部署。如果是服务升级已经有容器在运行怎么实现平滑替换而不影响业务呢配置Pod的健康检查Health Check只配置了ReadinessProbe没有用LivenessProbe。因为LivenessProbe在健康检查失败之后会将故障的pod直接干掉故障现场没有保留不利于问题的排查定位。而ReadinessProbe只会将故障的pod从service中踢除不接受流量。使用了ReadinessProbe后可以实现滚动升级不中断业务只有当pod健康检查成功之后关联的service才会转发流量请求给新升级的pod并销毁旧的pod。readinessProbe:failureThreshold: 4httpGet:path: /actuator/metricsport: 8090scheme: HTTPinitialDelaySeconds: 60periodSeconds: 15successThreshold: 2timeoutSeconds: 2线上运维的挑战服务间调用Spring Cloud使用eruka接受服务注册请求并在内存中维护服务列表。当一个服务作为客户端发起跨服务调用时会先获取服务提供者列表再通过某种负载均衡算法取得具体的服务提供者地址(ip port)即所谓的客户端服务发现。在本地开发环境中我们使用这种方式。由于Openshift天然就提供服务端服务发现即service模块客户端无需关注服务发现具体细节只需知道服务的域名就可以发起调用。由于我们有nodejs应用在实现eureka的注册和去注册的过程中都遇到过一些问题不能达到生产级别。所以决定直接使用service方式替换掉eureka也为以后采用service mesh做好铺垫。具体的做法是配置环境变量EUREKA_CLIENT_ENABLEDfalseRIBBON_EUREKA_ENABLEDfalse并将服务列表如 FOO_RIBBON_LISTOFSERVERS: [http://foo:8080](http://foo:8080/) 写进configmap中以envFrom: configMapRef方式获取环境变量列表。如果一个服务需要暴露到外部怎么办比如暴露前端的html文件或者服务端的gateway。Openshift内置的haproxy router相当于k8s的ingress直接在Openshift的web界面里面就可以很方便的配置。我们将前端的资源也作为一个Pod并有对应的Service当请求进入haproxy符合规则就会转发到ui所在的Service。router支持A/B test等功能唯一的遗憾是还不支持url rewrite。对于需要url rewrite的场景怎么办那么就直接将nginx也作为一个服务再做一层转发。流程变成 router → nginx pod → 具体提供服务的pod。链路跟踪开源的全链路跟踪很多比如spring cloud sleuth zipkin国内有美团的CAT等等。其目的就是当一个请求经过多个服务时可以通过一个固定值获取整条请求链路的行为日志基于此可以再进行耗时分析等衍生出一些性能诊断的功能。不过对于我们而言首要目的就是trouble shooting出了问题需要快速定位异常出现在什么服务整个请求的链路是怎样的。为了让解决方案轻量我们在日志中打印RequestId以及TraceId来标记链路。RequestId在gateway生成表示唯一一次请求TraceId相当于二级路径一开始与RequestId一样但进入线程池或者消息队列后TraceId会增加标记来标识唯一条路径。举个例子当一次请求会向MQ发送一个消息那么这个消息可能会被多个消费者消费此时每个消费线程都会自己生成一个TraceId来标记消费链路。加入TraceId的目的就是为了避免只用RequestId过滤出太多日志。实现上通过ThreadLocal存放APIRequestContext串联单服务内的所有调用当跨服务调用时将APIRequestContext信息转化为Http Header被调用方获取到Http Header后再次构建APIRequestContext放入ThreadLocal重复循环保证RequestId和TraceId不丢失即可。如果进入MQ那么APIRequestContext信息转化为Message Header即可(基于Rabbitmq实现)。当日志汇总到日志系统后如果出现问题只需要捕获发生异常的RequestId或是TraceId即可进行问题定位。经过一年来的使用基本可以满足绝大多数trouble shooting的场景一般半小时内即可定位到具体业务。容器监控容器化前监控用的是telegraf探针容器化后用的是prometheus直接安装了openshift自带的cluster-monitoring-operator。自带的监控项目已经比较全面包括nodepod资源的监控在新增node后也会自动添加进来。Java项目也添加了prometheus的监控端点只是可惜cluster-monitoring-operator提供的配置是只读的后期将研究怎么将java的jvm监控这些整合进来。MORE开源软件是对中小团队的一种福音无论是Spring Cloud还是k8s都大大降低了团队在基础设施建设上的时间成本。当然其中有更多的话题比如服务升降级限流熔断分布式任务调度灰度发布功能开关等等都需要更多时间来探讨。对于小团队要根据自身情况选择微服务的技术方案不可一味追新适合自己的才是最好的。作者简介徐鹏 Linkflow运维开发负责人声明本文为作者投稿版权归作者个人所有。【END】
