Deploy

欢迎访问我的GitHub https://github.com/zq2599/blog_demos 内容：所有原创文章分类汇总及配套源码，涉及Java、Docker、Kubernetes、DevOPS等； 概览 本文是《Kubernetes官方java客户端》系列的第七篇，以下提到的java客户端都是指client-jar.jar； 本文主要内容是通过java客户端发起patch请求，用来修改已有资源; 接下来会对kubernetes的patch做一些介绍，由于咱们这里的重点还是java客户端的patch操作，因此不会对patch的原理和概念展开太多，仅做最基本的说明能即可； 本文内容 这是篇万字长文，所以一开始就要明确本文的核心内容：开发一个SpringBoot应用并部署在kubernetes环境，这个应用通过kubernetes的java客户端向API Server发请求，请求内容包括：创建名为test123的deployment、对这个deployment进行patch操作，如下图： 接下来先了解一些kubernetes的patch相关的基本知识； 关于patch 是对各种资源的增删改查是kubernetes的基本操作； 对于修改操作，分为Replace和Patch两种； Replace好理解，就是用指定资源替换现有资源，replace有个特点，就是optimistic

笔者有幸经历了 IaaS（OS）、CaaS（Container），在这两年又听到了 FaaS（Funtion），这也是运维开发领域里的第三个阶段了吧，今天我将从一个不懂得开发的系统工程师视角以及结合之前的几篇系列文章为各位诠释这个概念。 本文来自 Serverless 社区用户「StatLee」投稿 一、简述 一开始听到 ServerLess 我以为是类似于 VPS（建站主机）亦或者是 VM、Container 之类的具备完整 OS 或半完整 OS 生态的一个全新开发方式，后来发现我完全理解错了，如果说传统的云计算是这样分层的： 那么 FaaS（ServerLess 为代表的的 Funtion As A Service）就是把 SaaS 再进行精细化拆分，可以看这张图就明白了（特别是红圈部分）： 传统以为 Application 就是业务的最终形态，可是随着以开发领域为首的「微服务」及运维领域为首的「SRE/DevOps」理念出来后，传统的业务运维明显已经不能满足新一代业务的需求，为了更贴合这些新的需求，实现： 模块拆分化（即一个功能作为一个模块，而非一个业务作为一个模块） 最小颗粒化变更（即分层变更，变更时通过合理调度时变更间隔缩短，实现快速迭代）的目的 云厂商最终在以往的「最终形态」上又拆分了 Function 出来，多个 Function 再组成 Application

1 以前在github发开源项目，都因为懒，从来不构建到中央仓库。最近因为其他人要用，联系我。希望可以发到中央仓库。我想，不就是mvn deploy嘛，开搞。一圈弄下来，发现真没那么简单。当中遇到了无数的坑，让我每一次都心里默默念到，发个项目，为何如此痛苦。 现将痛苦的过程详细记录下来。希望可以帮助到其他小伙伴少踩点坑。 首先，你需要到 sonatype 这个站点上去注册一个账号。这个页面长这个样子： 我当时以为我进错地方了，这不是jira吗。好吧。看url还是提issue的地方，这和发布项目有毛的关系... 好吧，点新建，项目选 Community Support - Open Source ，问题类型选 New Project 填就是了。注意的是Group Id这里要填你自己的拥有的域名，比如com.xxxx，没有的话，自己去注册域名去。填好之后就是等待审核。我搜了下，网上小伙伴说要等待3，5天。 3个小时后，我上去再去看，管理员给我回复了： 大致意思就是要你证明这个域名是属于你自己的。有2种方法，加一个txt类型的解析到你的域名里是最快的方法。 我的域名申请在腾讯云。登陆进去。找到域名解析设置。加进去txt类型的解析。主机记录填那个jira ticket名字，记录值是你这个ticket的链接url。 设置完了后，去回复管理员。然后继续等待。 管理员大概很快就回复了我

API 网关结合云函数 SCF 的使用场景非常丰富，本文将介绍如何基于 API 网关+云函数 SCF 快速部署 Serverless 的外卖订单系统。 消息推送使用的典型场景 外卖订单系统架构图 Demo 实战 1. 安装Serverless Framework npm install -g serverless 2. 初始化项目模板 sls init -t websocket-order 3. 查看项目目录 下载到本地后，查看项目目录结构如下： 包含 DB、网关、函数等多个子模块。 db 目录用于创建 PG Serverless 数据库实例 apigateway 用于创建对应的 API ： /bill 下单 API，HTTP 类型 /get_shop_info，获取店铺菜单 API /pgws，用于做消息推送的 websocket API 函数列表如下： 消息推送相关函数： 注册函数 ws_register.py， 配置 DB 的环境变量 传输函数 ws_trans.py ，配置 DB 的环境变量以及 apiid= 消息推送API 注销函数 ws_unregister.py ，配置 DB 的环境变量以及 apiid= 消息推送API 下单函数 bill.py ， 配置 DB 的环境变量以及 apiid= 消息推送API 拉取店铺信息函数 get_shop_info.py，配置

15 位青春洋溢的女团候选成员，百万次全网观众投票，节目播出后迅速霸占热搜前十位..... 在这激动人心的决赛之夜，Tencent Serverless 团队下的云 API 网关产品作为幕后英雄，利用其高并发、高可用的技术特性，支撑了节目投票环节顺利开展，面对全网粉丝狂热打 call 投票，顺利保障小姐姐们 C 位出道！ 不一般的投票 【投票】是一个很简单的功能，但是《创造营》的投票不一样。 《创造营》是直播节目，投票时间非常短。海量全网粉丝将在同一时间瞬时涌入，瞬间的大流量和高并发，对系统的高可用性提出了极高的要求。 《创造营》投票，将产生本届总冠军，是《创造营》决胜之夜的制胜环节，激动人心的时刻。投票系统的任何差池，都会对粉丝心理和节目效果造成重创。 在投票的关键时刻，为了保证女团小姐姐顺利出道，技术小哥哥采用了什么样的技术设计，保证了这种特殊场景下的投票功能高可用呢？ Serverless Serverless 是一种云计算技术的新趋势，一方面它使开发者在构建和运行应用时无需管理服务器等基础设施，将构建应用的成本进一步降低，实现快速迭代、极速部署；同时，Serverless尤其适用于高并发场景，无需预估流量大小，而会根据流量情况自动的进行扩缩容，整个过程无需人工干预；值得一提的是，Serverless 还是按用量付费的模式，避免了无用的资源开销，大大降低了成本。

上一篇 前端福音：Serverless 和 SSR 的天作之合 ，详细介绍了 SSR 相关知识，同时也提到了 Serverless 给 SSR 方案带来的福利。但它只是将 Next.js 应用部署到 Serverless 服务上而已，并不适合实际生产业务。为此本篇专门针对 Next.js 的 SSR 方案进行了探索和优化，一步一步带大家了解，如何基于 Serverless 架构部署一个实际的线上业务。 抢先体验： serverless-cnode 本文主要内容： 如何快速部署 Serverless Next.js 如何自定义 API 网关域名 如何通过 COS 托管静态资源 静态资源配置 CDN 基于 Layer 部署 node_modules 如何快速部署 Serverless Next.js 由于本人对 Serverless Framework 开发工具比较熟悉，并且长期参与相关开源工作，所以本文均使用 Serverless Components 方案进行部署，请在开始阅读本文之前，保证当前开发环境已经全局安装 serverless 命令行工具。 本文依然上一篇中介绍的 Next.js 组件 来帮助快速部署 Next.js 应用到腾讯云的 Serverless 服务上。 我们先快速初始化一个 Serverless Next.js 项目： $ serverless create

Bug的身世之谜 今天又分享一个问题解决的故事。请看下图框起来的错误，明显就是找不到这个class嘛！ 图片 下面我们按照正常人的思路去排查这个问题，既然找不到class那就先看这个依赖的jar包有没有，如果没有那就是铁证如山。 但是事与愿违啊，编译后的lib目录下真的有这个包order-api-2.0-SNAPSHOT.jar 还是不相信，于是将order-api-2.0-SNAPSHOT.jar解压了，看看里面到底有没有我们需要的class，真的有，此处心情沉重。 一般人到这里就会懵圈了，但我还年轻啊，脑袋还够用。接下来看看classpath的配置有没有问题，如果order-api-2.0-SNAPSHOT.jar不在classpath中，那么自然就是找不到class啊，机智的我。 于是查看了META-INF/MANIFEST.MF文件，发现里面依赖的是order-api-2.0-20200225.024541-15.jar， 什么情况，还加上时间戳了。 终于真相大白了，classpath中指向的是order-api-2.0-20200225.024541-15.jar， 但lib中只有 order-api-2.0-SNAPSHOT.jar。 所以找不到class是没有错的。 打包配置信息 Maven deploy的时候会自动给快照版本加时间戳，从下图可以看的出来： 图片

1.5 提高可用性-发布多节点的Node/Express网络应用程序 Kubernetes实战 - 从零开始搭建微服务 前言 在上一篇文章中，已经学习了如何简单地开发一个单层网络应用。 【Kubernetes实战 - 从零开始搭建微服务 1 - 使用kind构建一个单层架构Node/Express网络应用程序】 ，本文将在上一篇基础上，添加额外节点，目的在于提高可用性(high availability)。 关于可用性 high availability 在软件产品环境下，如何提高服务稳定性，进而避免用户流失，一直是架构师工作的核心。高可用性有一些基本的设计原则， 找到单一故障点/单点故障，就是在整个架构中，找到其中可用性最低的服务/点，增加冗余，以避免单点故障 可靠交叉(reliable crossover)，没找到很好的中文翻译，即，当多服务交叉在一起，互相依赖度极高，它们可能成为单点故障 及时发现故障 计算可用性 high availability A（可用性），MTBF(平均故障间隔)，MDT(平均修复时间) 举个例子，AWS S3 存储服务HA保证值就在99.99%，耐用性durability是11个9 - 99.999999999%。 kind 创建一个多节点集群 k8s设计本身就是在于降低容器devops维护复杂度，提高可用性。 在上一篇文章的介绍里

我在月初接入了 uwa的性能测试SDK ，需要提交一个development build的游戏安装包给uwa进行真人真机测试，本文说下如何判断安装包是否为development build。 直观上判断 如果是development build模式打包出来的安装包，在游戏的画面的右下角会有development build的水印，且在切换场景也不会消失 通过libunity.so判断 使用压缩软件，打开apk，查看libunity.so（在lib/armxx目录下），如果是development build话libunity.so 会比较大，以Unity2018.4.15f1为例 development build的有46MB。而release模式只有20MB 通过代码判断 Unity引擎提供这样一个接口来访问是否 development build，原文如下： In the Build Settings dialog there is a check box called "Development Build". If it is checked isDebugBuild will be true. In the editor isDebugBuild always returns true. It is recommended to remove all calls to

前言 上一篇博文 .NetCore 配合 Gitlab CI&CD 实践 - 开篇 ，主要简单的介绍了一下 GitLab CI 的持续集成以及持续部署，这篇将通过 GitLab CI 发布一个 .net core 项目,来带小伙伴们感受一下自动化的魅力，从此告别手动发布。 准备工作 创建一个空MVC项目来进行演示： mkdir hello-world cd hello-world dotnet new sln -n HelloWorld mkdir src cd src dotnet new mvc -n GitLabCIDemo cd ../ dotnet sln add .\src\GitLabCIDemo\GitLabCIDemo.csproj 完成以上创建后，用 vscode 打开应该是下面这个样子： 项目上传至 GitLab 在 gitlab 上新建一个 hello-world 的项目，将本地的项目上传。这个按照如下提示操作即可： 项目上传成功后，切一个 dev 分支出来，我这里的策略是，代码提交到 dev 分支是自动发布到开发环境进行验证的，生产环境是通过 master 分支打 tag 进行发布的。 切换到 dev 分支！ 切换到 dev 分支！ 切换到 dev 分支！ 添加相关脚本 在 hello-world 文件夹内创建 .build/docker 文件夹