baphsqca3imha
baphsqca3imha_个人页
baphsqca3imha
文章
2101
问答
0
视频
0
个人介绍
暂无个人介绍
擅长的技术
-
发表了文章 2022-11-25
钉钉宜搭全命题解析 | 学习笔记
开发者学堂课程【第八届大学生创新创业大赛阿里命题钉钉宜搭全命题解析：钉钉宜搭全命题解析】学习笔记，与课程紧密连接，让用户快速学习知识。课程地址：https://developer.aliyun.com/learning/course/1018/detail/15084钉钉宜搭全命题解析内容介绍：一、云钉低代码的技术演进过程二、企业数字化的旺盛需求三、云钉低代码助力业务创新新模式一、云钉低代码的技术演进过程云钉低代码的技术演进过程从最早的 1.0 时代及BPM驱动，以单一业务类型的单据实例为处理对象，人工活动的操作主要是审批，仅改变单据审批状态，聚焦解决单业务的流程在线和移动办公需求，加速单业务的审批现代化。到2.0时代主要是基于元数据驱动，多表单协同的业务在线和业务编排问题，业务编排强调多种业务类型的单据协同，包括领域内和跨领域的流程集成，编排的是业务。到了3.0时代，主要是基于数据驱动和云钉一体，随着阿里巴巴云钉一体战略的推进，加速的低代码和钉钉的连接和融合，让更多的生态和行业在线提供丰富的连接能力，让业务可以很容易的集成，实现互联互通。二、企业数字化的旺盛需求目前的代码应用已经超过240万，业务人员创建比例占超过60%，同时数据还在不断的高速增长。企业数字化的需求非常旺盛。三、云钉低代码助力业务创新新模式1、赛题1:基于“低代码+BPaaS”探索疫情时代的创新应用（1）命题背景在当前的疫情时代背景下，如何兼顾高效防疫和正常生产生活，从社区到企业、再到个人，都面临着社会协作方式的新挑战。数字化升级，成为应对这场大考的有力工且，作为数字化升级的推动者，钉钉不断自我选代，推出了 BPaaS+ 宜搭低代码平台，可在区防疫，复复产，灵活用工等多个场景中发挥重要价值。（2）命题内容①以钉钉 IM 的高效协调以及宜搭的低代码灵活搭建能力，支撑区域、社区结合自身特点，面向防控政策的频繁更新，建设区域内在“人员管理和调配”、“信息上通下达及统计分析”的动态，灵活，可调整的社会管控体系，实现精准防控，高效协调的效果②为劳动力密售型行业提供高效可靠的复工复产解决方案，一站式解决特定场景中海量人群的有检测，异常上报，疑难咨询等问题③为疫情期间的灵活用工场骨，提供便利化的工具，帮助相关人群解决其生活，工作中的痛点问题（3）答题要求①结合阿里云提供的 AI 技术 Faas 能力等，打造一款能切实解决行业痛点和难题的酷应用。②摆写应用的背景分析和设计文档，开发的应用要具备实用价值和推广价值。③为了快速开发应用、加深对低代码的掌握程度，建议参赛选手先通过阿里巴巴官方推出的低代码开发师初级、中级认证。2、赛题2:基于“低代码+AI”打造智能酷应用(智慧校园、智能制造、智慧园区、物联网)（1）命题背景随着中国数字化阶段的演进，低代码将在各行各业发挥更加关键的作用，让组织更灵动，更具竞争力。钉钉宜搭集成阿里云 AI 服务与FaaS 云开发，让云钉低代码扩展更智能，同时能大幅提升生产力。例如:疫情场景下通过低代码+阿里云的图象识别 +FaaS 扩展能力，来实现行程码的精准识别助力园区高效通行。在费用报销场景下，通过 OCR 发票识别，无需手动贴发票，员工随时随地都能提交费用报销，省时省力。（2）命题内容运用低代码技术，结合阿里云提供的 AI 能力(图像识别，智能翻译，语音识别等)，在智能制造，智慧校园，智慧园区，物联网等领域打造一款智能酷应用，助力企业数字化转型，为企业降本提效。（3）答题要求①结合阿里云提供的 AI 技术，Faas 能力等，打造一款能切实解决行业痛点和难题的酷应用。②撰写应用的背景分析和设计文档，开发的应用要具备实用价值和推广价值。③为了快速开发应用，加深对低代码的掌握程度，建议参赛选手先通过阿里巴巴官方推出的低代码开发师初级，中级认证。3、赛题3:基于“低代码+公益”助力乡村振兴（1）命题背景国家十四五规划提出了“乡村振兴”的重要战略，但是广大乡镇面临着基层数字化人才不足，数字化工具匮乏的困境。低代码开发即无需代码或者少量代码就可以开发一款应用，被视为未来数字经济时代人人必备的技能之一，通过将低代码新技术解决“乡村振兴”过程的痛点助力数字乡镇建设。（2）命题内容通过对乡村振兴当下痛点的充分调研，运用低代码开发方式，构建一个或多个功能完善的数字化应用，能够助力实现基层高效治理、拉动群众就业的目标。命题参考:农作物种植管理、防汛抗旱、电商销售、贫困户帮扶、零工就业等。（3）答题要求①使用钉钉宣搭开发应用，可根据实际情况利用阿里云提供的ALFaaS 等技术能力；②撰写应用的背景分析和设计文档，开发的应用要具备创新性，实用性，公益性"；③为了快速开发应用，加深对低代码的掌握程度，建议参赛选手先通过阿里巴巴官方推出的低代码开发师初级，中级认证4、赛题4:基于钉钉宜搭低代码开发平台探索提升企业管理效率的数字化创新方案（1）命题背景而对当前严峻的疫情形势和全球经济下行的压力，企业纷纷从原先的粗放型经营策略回归到精细化运营阶段，通过降本提效探索提升企业效益的新路径，低代码开发即无需代码或者少量代码就可以根据业务实际需求构建应用，成本低、效率高，被视为未来数字经济时代人人必备的技能之一，企业基层人员和管理者都可以将其运用在日常工（2）命题内容通过对企业运营中不同业务的痛点分析，运用低代码开发方式，构建体系化、功能完善、创新性的数字化应用，助力企业科学决策，帮助不同角色人员的日常工作实现数字化，提升企业管理效率，构建的应用可以涉及人事，财务，采购，行政、IT、生产，销售等场景。以行政场景为例，参赛选手可以开发出物咨管理，访客管理，车辆管理等（3）答题要求①使用钉钉宜搭开发应用，并使用连接器，大屏等进阶能力，也可利用阿里云提供的 ALFaaS 等技术能力:②撰写应用的背景分析和设计文档，开发的应用要具备创新性、实用性，以及商业推广价值;③为了快速开发应用、加深对低代码的掌握程度，建议参赛选手先通过阿里巴巴官方推出的低代码开发师初级、中级认证，5、赛题5:基于钉钉宜搭低代码开发平台探索具有行业应用场景的创意方案（1）命题背景数字经济时代已经来临，借助于云技术的发展，大型软件将向专业细分化发展，但目前市面上的大型软件个性化程度低，价格昂贵，企业自建系统人工，时间成本高，低代码开发，让企业能按照自身实际需求像积木一样搭专尾的应用软件，降低开发成本和门槛，通过可视化拖拽的方式，快谏构建行业解决方案，覆盖教育、互联网、医疗、制造、建筑、零售、政务等多个领域，不断激发个人和组织的创造力，助力百行千业加速数字化转型。（2）命题内容结合低代码技术，面向教育、互联网、医疗、制造、建筑、零售、政务，工业、农业、公益等行业，构建具有行业应用场量的创意方案，有效助力千行百业数字化转型，提升产业运转效率。（3）答题要求①基于钉钉宜搭低代码开发平台搭建应用，可根据实际情况有效利用阿里云提供的 AI 技术，Faas 能力等②撰写应用的背景分析和设计文档，应用需求梳理完整，作品架构完善，合理，具有创新性，方案具备实用价值和推广价值③为了快速开发应用，加深对低代码的掌握程度，建议参赛选手先通过阿里巴巴官方推出的低代码开发师初级，中级认证。6、赛题6:基于钉钉宜搭低代码开发平台探索智慧党建应用场景方案（1）命题背景目前市面上缺少符合学校、企业等场景的党建系统，通过低代码方式结合组织实际需求构建个性化智慧党建系统，可以快速实现党建工作的数字化，提高党建工作开展的效率以及效果。（2）命题内容使用低代码平台，以入党积极分子，发展对象，预备党员，正式党员四个阶段为基础，为党员，党支部，二级党委，校党委等提供一整套智慧党建系统，打造集党建宣传，党员教育，党务工作，党建管理为一体的智慧化平台，保证党员发展的流程标准，信息准确，为学校各项党建工作顺利推进提供了坚实保障。（3）答题要求①基于钉钉宜搭低代码开发平台搭建应用，可根据实际情况有效利用阿里云提供的 AI 技术，Faas 能力等②批写应用的背景分析和设计文档，应用需求梳理完整，作品架构完善，合理，具有创新性，方案具备实用价值和推广价值。③为了快速开发应用，加深对低代码的掌握程度，建议参赛选手先通过阿里巴巴官方推出的低代码开发师初级，中级认证7、赛题7:基于钉钉宜搭低代码开发平台探索新能源汽车供应链管理酷应用方案（1）命题背景新能源汽车是信息技术与制造体系的全面融合，是产业发展的大势所趋，也是新动能的重要支点，新能酒汽车供应链管理可以高效的协助采购及供应商上下游的跨企业协同工作，通过钉钉宣搭低代码平台，企业按照自身需求像搭积木一样搭建专属的应用软件，降低开发成本和门槛，快速实现应用落地。（2）命题内容通过低代码 +AI+ 连接等方式，建立新能源汽车行业的供应链管理应用，覆盖采购及供应商上下游的跨企业协同管理，构建完整的供应链管理酷应用方案。（3）答题要求①基于钉钉宜搭低代码开发平台搭建应用，有效利用阿里云提供的AI 技术，Faas 能力等②聚焦在新能源汽车行业供应链管理的数字化转型，需求梳理完整，作品架构完善、合理，具有创新性，方案具备实用价值和推广价值③为了快速开发应用，加深对任代码的掌握程度，建议参赛选手先通过阿里巴巴官方推出的低代码开发师初级，中级认证。8、赛题8:使用宜搭低代码平台解决公益机构数字化转型问题（1）命题背景码上公益平台( https://greencodealiyun.com/ )是阿里云搭建的技术志愿者与公益机构互动的平台，自2017年建议以来，已有336家机构入驻并提出数字化转型需求，其中项目管理系统、志愿者证书发放系统、申请管理系统的数字化是公益机构普遍的诉求。通过钉钉宜搭低代码平台，企业按照自身需求像搭积木一样搭建专属的应用软件，降低开发成本和门槛，快速实现应用落地。通过公益平台与低代码技术的结合，推动公益平台实现数字化转型（2）命题内容请使用宜搭产品完成以下系统的搭建，使其可以作为模板应用到公益机构的实际工作中:①申请管理系统:用干外部社会受益人向公益机构申请咨助的场景，需具备管理申请人的身份信息，证明材料，求助审批流程，申请结果反馈，申请讲度提醒收款确认及反馈等功能。②项目管理系统:用于公益项目全流程管理场景，需具备项目立项，外部受助人申请审批流，项目回访，项目人员管理，项目人员批量上传更新补充资料，服务资金拨付，受助人反馈，项目、受助人档案管理分析等功能③证书发放系统:用于捐赠证书及志愿者证书发放，需具备根据不同场景需求，生成证书、证书下载等功能。④服务捐赠管理:用干管理公益机构服务，物咨管理场景，需具备会捐赠物咨申请，入库、发放物咨的动态统计，库存预警管理分析，捐赠人信息维护等功能⑤合作伙伴管理:用于管理公益机构项目落地过程中涉及的合作伙伴，志愿者管理场景;需具备伙伴分类，权限，考核积分，人员更替，具体合作伙伴项目效果等管理。⑥信息档案管理:用干管理机构项目及合作机构项目落地情况咨料管理场景，需具备咨料批量，定期，分类上传管理，自定义批量下载，按照具体条件查询筛选导出，具体不同权限人员资料查询、调用管理等功能。在此基础上，还可以增加数字化大屏、数据分析管理等功能以帮助公益机构更高效地进行决策，码上公益平台(https://greencodealiyun.com/)上有大量的由公益机构提出的真实诉求，建议参与答题的同学进行实地调研，以便开发出真正能够落地使用的系统。（3）答题要求①基于钉钉宜搭低代码开发平台搭建应用，需具考虑到必要的权限分级管理及审批流程，可根据实际情况有效利用阿里云提供的 AI 技术，Faas 能力等②擢写应用的背量分析和设计文档，参寒作品需求梳理完整，主要功能可用，能够实际落地，架构完善、合理，具有创新性，方案具备实用价值和推广价值③为了快速开发应用、加深对低代码的掌握程度，建议参赛选手先通过阿里巴巴官方推出的低代码开发师初级、中级认证。9、赛题9:基于钉钉宜搭低代码平台开发行业化插件与扩展（1）命题背景低代码平台技术日渐成熟，各大厂商仍有较多行业定制或扩展的需求无法满足，钉钉宜搭与插件机制的融合，允许用户或技术团队建立行业化的插件和扩展来丰富平台能力，将释放出更强大的自动化，智能化能力，充分发挥低代码的低门槛优势，赋能企业应用，满足企业数字化升级转型需要。（2）命题内容低代码已成为企业服务行业最火的平台产品类型，但当前仍然外在起步阶段，各大厂商仍有较多行业定制或扩展的需求无法满足，以钉钉宜搭低代码平台为例，大多提供了插件机制，允许用户或技术团队建立行业化的插件和扩展来丰富平台能力，并通过商业化机制获得收入。（3）答题要求①基于钉钉宜搭，创建具备商业化服务能力的自定义组件或插件，服务于某个特定场景及行业;②完成的方案需要具备实用性及商业化可能性，上架到开放能力市场，吸引行业用户试用及体验。③为了快速开发应用、加深对低代码的掌握程度，建议参赛选手先通过阿里巴巴官方推出的低代码开发师初级、中级认证。10、阿里云技术支持社区https://developer.aliyun.com/learning/topic/internetplus命题解读5分钟命题解读:包含命题解读、命题要求、考察要点、解题思路等 学习资料 为赛题提供相匹配技术课程、体系化学习路线提，供参赛者学习 场景动手体验 提供赛题所涉及的云产品试用与云端实验沙箱 环境供参赛者动手实操 提赛前训练营 提供针对赛题的专项培训，阿里云专家讲解，主力参赛者取得更好成绩相关的技术文档和学习资料从官网社区去看。11、低代码开发师能力图谱当前也在抽象定义低代码的一些能力图谱，目前分为初级、中级、高级三个大类，三个大类根据不同的技能要求也分了九个小类。同时越来越多的企业提供低代码工程师的岗位，也有越来越多的开发者和业务人员用低代码去丰富自己的技能。低代码开发师人才认证企业数字化转型的核心推动者初级：面向人群:业务人员认证目标:具备自建基础应用能力 中级：面向人群:业务人员认证目标:具备自建复杂应用能力 高级：面向人群:开发人员认证目标:具备开发集成能力实现应用互联互通提供一些低代码开发认证，人才认证，在参加比赛的时候可以尝试去学习和申请低代码开发师的认证。
-
发表了文章 2022-11-24
【视频】云原生数据仓库 AnalyticDB MySQL 版 _解析与实践1｜学习笔记（三）
开发者学堂课程【数据仓库 ACP 认证课程：【视频】云原生数据仓库 AnalyticDB MySQL 版 _解析与实践1】学习笔记，与课程紧密联系，让用户快速学习知识。 课程地址：https://developer.aliyun.com/learning/course/928/detail/14623【视频】云原生数据仓库 AnalyticDB MySQL 版 _解析与实践1（2）权限与数据安全∶用户用户账号和认证︰账号格式:ALIYUN$user_account@aliyun.com认证需要使用AcclessKey用户类型:.OWNER:数据库拥有者，开通云原生数据仓库服务，并创建数据用户∶被授权的数据库用户，由OWNER添加，无需开通云原生数据仓库服务RAM子账号︰支持RAM（阿里云访问控制）子账号登录和使用云原生数据仓库主账号可建多个子账号，通过授予授权策略，使子账号在一定条件下可以访问云原生数据仓库子账号访问云原生数据仓库的MySQL协议端时需要使用其的Access Key ID/Secret作为用户名和密码（3）权限与数据安全∶权限模型AnalyticDB for MySQL集群支持如下粒度的权限控制:集群、数据库、表、列、行级（基于视图)。 DBTColCommentsSELECT√√√查询数据INSERT...SELECT...FROM...√√√执行Insert.Select权限UPDATE√√√执行Update权限TRUNCATE TABLE√√×执行Drop权限SHOW√√×列出数据库、表、视图内部对象(Global、Database )、列出表内部对象 (Table[View] )ALTER√√×修改表/视图/数据库定义DROP√√×删除数据库、表或分区(Global、Database )、删除表或分区(Table[Group])CREATE√√×创建数据库(Global )、创建表/表分区/视图(Database )INSERT√√√执行Insert的权限DELETE√√√执行Delete的权限ALL[PRIVILEGES]√√√以上所有权限（4）权限与数据安全:SQL审计SQL审计功能可以实时记录数据库DML和DDL操作信息，并提供数据库操作信息的检索功能，提高云原生数据仓库AnalyticDB MySQL版的安全性。SQL审计日志记录对数据库执行的所有操作。通过审计日志记录，您可以对数据库进行故障分析、行为分析、安全审计等操作。搜索可以按照数据库、客户端IP、执行耗时、执行状态等进行多维度检索，并支持导出搜索结果。3.智能索引ADB为表的每个字段智能构建索引，目前支持五种类型∶字符串类的 Invert 索引、 bitmap.索引、数值类的KDTree索引、JSON索引和向量索引;不同类型的索引可以实现列级索引多种条件(交、并、差）任意组合，查询时无需建组合索引，通过Index CBO智能动态筛选索引下推，通过谓词计算层进行流式渐进多路归并输出倒排索引∶分区表的所有列（适用Bitmap索引的列除外）都建了倒排索引，key为排序的列值，value为对应的RowID list，所以对于任何列进行FILTER(WHERE key=value)或者JOIN查询都非常高效。Bitmap索引∶对于值重复率高的列，建立Bitmap索引。KDTree索引∶为了加速范围查询，对于类型为数字的列同时建立了KDTree索引。（1）行列混存的块索引（2）块索引即块的元数据信息︰分区元数据︰分区总行数，单个block中的列行数等信息;列元数据∶列值类型、整列的MAX/MIN值，NULL值数目，直方图信息等，便于加速查询;列Block元数据︰该列的MAX/MIN/SUM总条目数(COUNT)等信息,便于加速查询。说明∶复杂类型数据(json , vector )存储采用统一大小的块组织存储，按顺序存，采用稀疏索引查询4.数据存储冷热分离（1）冷热数据分层AnalyticDB可以按表粒度、表的二级分区粒度独立选择冷、热存储介质，AnalyticDB数据写入时，数据会首先进入热空间SSD上，当热存储数据积累到一定程度或者用户指定的冷表策略时会自动调度后台的Build任务，把数据迁移到冷存储空间。冷数据指的是访问频次较低的数据，采用低价的HDD存储，满足存储空间的需求。热数据指的是访问频次较高的数据，采用SSD存储，满足高性能访问的需求。可以执行CREATE TABLE语句指定表的冷热存储策略为︰全热存储（数据全部存储在SSD )、全冷存储（数据全部存储在HDD )、冷热混合存储（指定一定数量的分区存储在SSD，其余数据存储在HDD )。创建表可以指定存储策，等于 Hot、Cold、Mixed代表不同的热数据，冷数据来混存，在混存时候需要指定热分区的个数，指定热分区个数为3，新来 的数据放入热分区中，继续放入会增多，其中一个会转HDD中存储冷热分层高性价比，完全按量付费冷热策略轻松定义只需指定表的冷热策略即可享有冷热存储能力，无需额外购买资源冷热分区自动迁移异步迁移，业务无感知，不影响读写查询和内外部接口统一在离线一体化，数据强一致（2）冷热数据存储诊断表AnalyticDB MySQL版弹性模式集群版( 3.1.3.5及以上版本）支持数据的冷热分离存储，用户可以通过查表的方式查询某一张表的冷热数据存储布局情况。查询所有表的存储状态∶select * from information_schema.table_ usage;查询单个表的存储状态︰select * from information_schema.table_usage whereitable_ schema="$schema_name' and table_name='Stable name' 在表A中，数据有两个分片分布在两个不同的节点上，如果指定热分区是2，其实在每一个分片上面都满足这个热数据。分区的个数是2，但实际上热分区是p3p4p5实际显示的hot_partition_count大于用户定义的hot_partition_count。5.物化视图物化视图是数仓领域的核心特性之一。不同于逻辑视图( view ) ，物化视图( materializedview )会持久化视图的查询结果。物化视图可用于加速分析，并能简化ETL，适用于多种场景，例如报表类业务，大屏展示需求，来自BI工具的查询等等。创建物化试图的语法：CREATE MATERIALIZED VIEW <mv_name>[MV DEFINITION][REFRESH COMPLETE [ON<DEMAND|OVERWRITE>][STARTWITH date][NEXT date]]As<QUERY BODY>;#指定列建立索引，默认全部列建立索引CREATE MATERIALIZED VIEW myview (INDEX(name),PRIMARY KEY (id))DISTRIBUTED BY HASH (id)ASSELECT id, name, age FROM base;#指定分区键和注释CREATE MATERIALIZED VIEW c (name varchar(10),value double,KEY INDEX_ID(id)COMMENT "id",CLUSTERED KEY INDEX(name, value),PRIMARY KEY(id)）DISTRIBUTED BY hash(id)PARTITION BY value(date_format(dat,"%Y%m%d"))LIFECYCLE 30COMMENT"MATERIALIZED VIEw c’ASSELECT * FROM base;物化视图客户案例使用物化视图降低客户查询延迟时间。举例生意参谋∶是阿里巴巴旗下为千万商家提供的一项重要产品服务，帮助商家及时分析店铺运营情况。尤其是在大促期间，面对突发的流量和海量的数据，数据分析尤为重要。利用物化视图，可以大幅降低延迟时间。将每小时展示信息结果存储到物化视图中，每次查询只需要查询物化视图即可，平均每次查询时间降低至100毫秒。
-
发表了文章 2022-11-24
云原生技术架构成熟度模型解读 | 学习笔记
开发者学堂课程【云原生架构实践：云原生技术架构成熟度模型解读】学习笔记，与课程紧密连接，让用户快速学习知识。课程地址：https://developer.aliyun.com/learning/course/1054/detail/15548云原生技术架构成熟度模型解读 内容介绍：一、总体介绍二、云原生技术架构成熟度（CNMM-TAS）三、云原生业务应用成熟度（CNMM-TAS）四、云原生业务应用成熟度（CNMM-TAS）今天带来《信通院云原生能力成熟度》标准解读以及测评结果介绍。今天的分享主要包含四部分内容，首先先总体介绍一下云原生成熟度相关标准的产生背景，以及当前云原生的发展趋势。后面三部分内容是基于信通院的原生能力成熟度标准里的主要三大内容，包括技术架构，业务应用和架构安全三方面去做详细的标准解读，和测评的结果的分析，这里还包含友商参与测评得到结果的对比。 一、总体介绍1.云原生的趋势首先进入第一部分，过去几年云原生技术得到了高速发展，原生技术能够给企业带来非常高的应用开发的效率提升，所以 IDC 预测到2024年，由于采用了微服务、容器动态编排和 DevOps 等技术，新增的生产级原生应用在新增应用的占比中将从2020年的10%增加到60%。到2024年，数字经济的发展将孕育出超过5亿的新应用和服务，这与过去40年间出现的应用数量相当。同时到2025年，超过一半的中国五百强企业将成为软件生产商，超过90%的应用程序为云延生的应用程序。到2025年，2/3的企业将每天发布新版本的软件产品。2.云原生技术已大规模进入企业生产环境这都是云原生技术的发展能够给企业带来的效率提升的非常直观的影响。在去年信通院发布的中国云原生用户调查中，也看到有接近半数的企业客户已经把容器技术应用在了核心生产环境，容器技术的推广效果非常好，并且相较2020年有了大幅的占比提升。在微服务领域，超过八成的用户已经采用或计划采用为服务架构进行应用开发，微服务已经成为了应用开发的架构优选。在 serveries 领域，作为原生领域的一个新兴的技术引进方向，目前在核心业务中使用 serveries 的用户也已经接近了两成，已开始和计划使用 serveries 技术的用户超过七成。市场的潜力非常大。3.云原生技术价值已被认可，规模化应用仍有瓶颈但在这种情况下大量的企业客户，一方面认同云原生技术能够带来价值提升。比如提升资源利用率，提升弹性伸缩效率，提升交付效率，提升系统运维效率等等。并且从趋势来看，2021年对于这些价值的认同点相较2020年得到了大幅提升。比如企业客户对于原生价值的认同感是大幅的提升，但同时也看到，企业客户对于云原生技术选型存在的顾虑也在一定程度上得到了提升，这里面主要包括大规模应用原生技术对于安全性、可靠性、性能和业务连续性方面的顾虑，同时对于高速发展的技术在带来的过度复杂，学习成本高的问题也是企业客户非常关注的点，所以可以看到，包括跟很多客户去做沟通时，企业客户在面对原生技术的时候，通常处于比较纠结的状态。一方面希望企业的 it 架构能够享受技术发展的红利，能够享受文化带来的效率提升、成本降低，但是同时又对于过于复杂的技术，对于自己的技术人员，对于相关技术的控制力不足可能带来的一系列问题，有非常大的一个顾虑。4.云原生产业供需仍需打通最后“一公里”这里简单把这些顾虑，分成这样的供给侧和需求侧两端来看。因为云原生其实已经是大势所趋，但是在企业客户执行层面确实存在了诊断难、规划难、选型难等问题。站在技术供给的角度来看，技术及发展及产品的发展脉络是很难把握的，因为云原生技术不像中间这样，或者像虚拟化技术一样已经发展的很长一段时间。云原生技术经过了六年的高速发展，其中经历了非常多的技术路线型改变，在这个过程中用户对于发展脉络其实是比较难把握的，同时用户需求又是比较多变的，缺少一个主线。同时技术押宝的风险还比较高。在用户需求侧整体的价格规划缺乏标准的参照，当用户在设计业务系统架构时，其实没有一个很好的权威的来说明怎么去应用云原生技术，同时在建设的路径方面也不够清晰，技术路线的庞杂也比较难筛选，自身架构的技术水平缺乏对比，现实需求和供应商能力不能精准对应等等需求侧的困难。所以站在供给和需求两端来看，其实是缺少一个行业权威建设的原生建设的指南，能够给到企业客户在规划自身 it 架构云原生化的过程中，一步一步演进的操作指南。这个指南需要解决什么？解决用户侧实际问题为导引，并且以行业技术发展的趋势为指引，来实现用户原生化的一个快速和高效落地。5.阿里云《云原生架构成熟度模型（2022）》所以基于这样的一系列的问题，阿里云的云原生团队也于2019年底和2020年初，推出了阿里云的云原生架构白皮书，云原生架构白皮书是把阿里巴巴过去几年，在云原生领域的践行和推进的经验进行了总结和抽象，并且在云原生架构白皮书中也提出了云原生架构成熟度这样的模型。模型主要包含服务化能力，弹性能力，无服务器化程度，可观测性，韧性能力，自动化能力这六个指标维度，并且每个指标维度给出了0到3分的发展阶段评分，客户可以基于这样的维度，对于自身的 it 架构系统进行比较详细的评分，并且基于总分能够整体定级，包含了零级，基础级，发展级和成熟级，基于这样的整体的云原生成熟度模型有助于企业站在全局的视角看自己的 it 架构以及云原生化的成熟度的情况。6.信通院云原生标准化工作总览站在信通院的角度，信通院从16年开始也开始做云原生相关的航标和白皮书的相关的制定，目前已经覆盖了像容器为服务、serveries 等等相对比较完整的云原生的评估体系，但是可以看到过去的航标是点状分布的，并不能很好的站在整体的视角去评估整个企业在落地过程中的成熟度、表现情况。所以在这种情况下，2020年初，由信通院牵头，拉着30多家企业一起去共同制定这样的云原生能力成熟度的评估体系，这个体系目前发展到现阶段，总共包含了三部分内容：第一块是技术架构的成熟度，第二块是业务应用的成熟度，第三块是架构安全的成熟度。在建立整个成熟度体系的过程中，也是参考了阿里云的云原生应用平台团队推出的成熟度模型，并且这个标准还在发展中，目前上周进行了新一轮的开会讨论，第五部分应该是云原生中间成熟度标准。7.云原生能力成熟度体系是联接供需双方的重要纽带来详细看一下信通院的这套云原生能力成熟度体系是如何建设的，其核心目的就是为了连接供需双方，加固云原生的能力。可以看到在这里边把它简称为 T、A、S 这样的三层结构，T 就是技术架构成熟度模型，它主要面向的是供给侧，所谓的供给侧主要包含了云原生技术服务商，比如说阿里云就是云原生技术服务商，或者面对于大客户内部的企业平台的 it 部门。在需求侧有业务应用的成熟度就是 A，那需求侧主要是企业的业务线，或者阿里云的业务型企业客户，同时还需要负责架构安全的成熟度评估模型，这是供给侧、需求侧都需要去参考的价格安全的成熟度评估体系。这套体系建立好后给企业客户能够带来什么价值？第一是多维度的把脉，能够准确定位企业云原生化的改造阶段；第二是差异化分析，详细诊断企业当前云原生能力的建设短板；第三是基于企业当前的发展阶段定制化提升，明确输出企业未来能力改进方向和计划8.CNMM-TAS（云原生成熟度体系）：能力魔方和特性雷达详细拆解云原生成熟度体系可以包含一个体系，三个视角，五个特性。所谓的体系就是刚才提到的三角关系，应用服务语，技术架构语以及架构安全语。三个视角主要是包含了业务应用的建设视角，着眼于业务应用、拆装结偶，充分融合底层架构技术实现的应用任性，这主要是面向应用架构的合理性视角；第二个视角是 it 技术平台的视角，通过技术架构建设视角，着眼于服务全局的技术架构、技术路线和全景能力规划；第三个视角就是系统安全的视角，安全能力建设视角，着眼于新形态技术架构下的端到端的安全防护的能力构建。基于这样的三个视角，再通过五个特性做特性雷达的详细的阐述，五个特性主要包含了弹性、自动化、可观测性，自愈、高可用，这五个特性也是后续在制定相关的测试用例和评分标准时，主要参考的五个维度。二、云原生技术架构成熟度（CNMM-TAS）第二部分针对于云原生能力成熟度模型里，最重要的技术架构成熟度做一个详细的裁剪。可以看到云原生技术架构成熟度模型的第一部分是技术架构，这其中涵盖了4个能力域，12个过程域和46个能力子项，以及最终在测评时有476个细分能力要求，通过这样的测评能够帮助用户快速对照定位技术架构的水平，并根据自身业务需求结合模型高阶能力定制技术与架构的研究方向。详细看一下这四个领域，从底往上，首先是偏向 RMA 的资源管理域，资源管理又包含了融合、调度、存储、计算、网络环境等相关一系列的成熟度标准评估；再往上是运维保障域，基础运维、可观测、高可用是运维保障域里核心要去做测试的三个过程域；再往上是研发测试域，对应有研发支撑和测试支撑；最后是应用服务域，主要包含应用编排，部署应用自理和应用中间件等三个过程域。基于这样四个能力域的一个详细的定义，把最终的测评结果分为初试级，基础级，全面级，不朽级和卓越级五个成熟度等级。先来看初始级，初始级的定义主要是技术架构局部范围开始尝试云原生化应用，并取得初步成效，这里主要突出的特征就是容器化；基础级的定义，是技术架构在局部范围内进行深入的云原生化应用取得了比较良好的效果，突出的特征就是有云原生平台的建设，突出特征是平台化；全面级的定义是技术架构在更大范围内的体系化应用云原生技术，具备关键技术模块儿的相关能力，突出的特征就是体系化，相当于是在云原生相关技术在企业内部的体系化落地；优秀级的定义主要是技术架构全面云原生化，各技术模块以高度云原生化架构的弹性、自动化、自愈能力已有全面提升，突出的特征就是规模化；第五个卓越级的定义是技术架构已完成全面云原生化改造，且每个技术模块功能已经相当完善，能够很好的支撑上层应用，突出的特征就是智能化。目前技术架构的成熟度测评的参与的企业非常多，目前腾讯和华为也已经通过了相关的测评，这个结果后面可以详细描述一下。接下来介绍一下四个主要的能力域的测评情况，由于这里包含了非常多的能力指向和过程域，这里就不一一拆解每一个能力域，只能选择一到两个这样的标准来感受一下，不同的成熟度对于技术和产品的能力要求是怎么样。因为整体目前相关的标准的最终定稿还未发布，所以现在给大家看到的标准，实际上是修订过的版本，而且也不一定是最终版，所以现在这里大概有整体的了解就可以，具体的还是以信通院发布的标准为主。首先是资源管理域，资源管理域的弹性能力这个板块，从级别角度来看，刚才也提到了整体评测都是以一到五级作为递进关系。在一级里，作为资源管理率的弹性能力，要求支持计算资源的扩缩容就可以。而二级在一级的基础上需要达到支持虚拟机规格的弹性能力。第三级在二级基础上需要达到支持集群的扩容效率的提升，比如实现百节点分钟级的扩容能力。第四级在三级的基础上，需要支持容器的快速弹性以及支持压秒级的容器启动，并且支持函数计算等相关信息业务的扩容效率和系统时长，比如千实力的分钟级扩容能力。第五级在第四级基础上需要达到支持压秒级的沙箱容器弹性启动能力，支持容器的应用扩展，效率提升，如万实力的分钟级扩容能力。可以看到每一级的能力提升相对都比较明显，在这个资源管理域里，从下图可以看到能力测评结果可以看到，在计算环境、网络环境、存储环境三个主要领域中都得到五级的最高分，在融合调度领域得到了四级，但并不表示能力只在四级，其实是因为最终在设计相关的测试用例时只给到了四级。这次的领域测评，主要产品的主要有容器服务、Serverless容器服务、函数计算、Serverless 应用引擎、存储产品线、弹性计算产品线等相关的一系列产品都在测评中有使用。第二个领域是运维保障域，拿容灾备份这一栏来看，第一级能力要求是支持简单的容灾设计，支持本地云备容灾能力，支持应用数据全量备份能力，这是基础的容灾要求；第二级在一级的基础上需要支持异地能备容灾能力，支持应用数据增量备份能力，支持手动恢复能备能力；第三级在二级的基础上需要达到支持同城生活容灾能力，支持同城生活应用数据，应用配置备份存储，支持同城生活的应用数据恢复，按备份的应用配置拉起应用；第四级在三级的基础上需要支持两地三中心的业务架构。第五级在四级的基础上需要支持异地多活容灾能力，支持异地双活的应用数据备份存储，支持异地双活的应用数据恢复及应用拉起。每一个能力的层级，其实都是对于备份相关能力提出了更具体、更高阶的能力要求，所以在人为保障在领域里面，主要分为基础运维应用的过程域和可观测过程域与高可能观测域，整体得到了五个五级三个四级的测评结果。在这个领域测评中主要涉及到的阿里云产品主要包含了，应用实时监控服务 ARMS、Prometheus 监控，链路追踪 Tracing Analysis，应用高可用服务、日志服务，混合云容灾服务和容器服务 ACK等。第三个领域是研发测试领域，这个领域的具体要求，以代码资产管理代理相关为例子来看。第一级支持集中式的代码管理等传统技术，基本上目前企业都能够做到；第二级在一级的基础上，采用电子方式管理源代码，代码资产具备每日备份机制；第三级在二级上需要达到以工具方式对应用过程中的文档进行统一管理，支持以制品库方式对研发中产生的制品，包括挖包、镜像等进行统一管理；支持使用经过验证的线上 SARS 化工具进行能力补充，如产品定义相关；第四级在三级基础上需要达到支持统一账号登录前输工具和系统，对暂不支持的例如线上 SARS 其账号由公司而不是个人管理，公司采用统一一致的研发相关数字资产管理体系，不存在实践给库，或者采用未受监管的系统管理研发过程中的数字资产。第三点是对于内部研发人员、外部服务人员的账号，可以实施不同的管理和权限策略；第五级在四级的基础上需要增加支持各代码管理系统间的联动与关联分析，支持基于研发产生的数字资产进行质量分析，如代码扫描，支持基于研发产生数字资产进行效能分析，如效率看板等等。在研发测试域里面主要包含了研发和测试两个过程域，目前测试的结构的研发支撑域里面，获得了一个四级和七个五级，测试支撑域里面获得了五个四级和两个五级。这是这个领域主要产品，包含云效、云端开发 DevStudio、性能测试，先知（安全众测），渗透测试，API 网关，阿里巴巴 Cloud Toolkit、移动测试等等相关产品。最后再来看看应用服务域，以服务化能力看应用服务域的成熟度能力要求。第一级是零散的使用复制治理相关产品，不具备产品化能力，无法实现快速复制到另外一个项目上，无统一的系统计算方案；第二级是要求已初步具备产品化能力，可快速复制到另一个项目上，拥有统一的服务治理平面，在统一的平台上可以完成服务自理能力的配置，统一的系统计算方案，例如认证机制、接口设计等；第三级在二级的基础上需要支持微服务自理平台自身使用微服务架构构建，可为虚拟机、容器、服务网格等提供服务自理服务。第三是各组件均可支持，多实力同时提供服务。第四级在三级基础上，需要增加可支持大规模微服务系统治理，提供完善的系统接口和安全的访问机制，向外提供丰富的服务治理服务，拥有高可用设计和容载架构，能够达到 ASM 的要求；第五级又是最高级，在实际上又增加了服务治理组件，均可实现在线更新，提供多中心、多活、单元化等高可用的架构支持，可以同时纳管大量不同种类的应用集群，这是服务化这块儿物体能力的分配要求，那在应用服务域参与测评的产品主要包括MSE、ASM，ADP，容器服务 ACK以及 EDAS，还有 SAE 等相关产品。在最终的测试结果，在应用中间件的过程域中得到了两个4级，两个5级的评价，在应用自定义获得了三个4级，2个5级的评测结果，在应用编排领域获得了两个5级的测评结果。基于四个领域的分别测评，可以看到信通院推出这样的技术架构成熟度体系后的首批，也是首家完整通过所有的4个云原生能力域，12个过程域，46个能力指向，476个细分能力要求的厂商，另外也覆盖内部数10条业务线以及50多款的云原生产品。全方位的考察阿里云的云原生产品的服务丰富度，同时技术人员对于信通院的测评人员，对于整个测试过程其实要求是非常细致的，最终产生将近400页的测评报告，对每一个能力指向都有非常详细的测评过程的记录以及数据的记录，充分表明了整个测评过程中的客观性和真实性。同时最终得到的测评等级是云原生成熟度等级是四级，并且在四个子领域都得到了 L4+的顶级的结果。这里也简单说一下，为什么没有五级，因为成熟度的标准，主要是面向于未来发展的，所以说在测评过程初，就基本上和信通院达成了一致的态度，就是在首批测评过程中不会产生5级要求，因为这样对于未来的发展方向不具备指导性，所以一开始就定义最高级就是四级。同时也可以看一下友商的测评情况，在云原生技术架构成熟度中首批测评的客户里，最关注的其实还是华为和腾讯两家友商。目前结果是四个 L4+，华为的结果是三个 L4+和一个 L4。腾讯只完成了三个过程域，三个能力域的测评，具体原因并不清楚。其得到的结果就是两个 L4+和一个L4。目前这是技术架构成熟度相关的情况。三、云原生业务应用成熟度（CNMM-TAS）第三部分简单介绍一下云原生业务应用成熟度相关的内容，因为业务应用成熟度，主要是面向业务系统平台的构建能力间的评估评测。所以在此过程中，阿里云作为云服务提供方不参与这一项测评。作为 TAS 模型里边的 A，其整体覆盖了3个能力域，15个过程域，能够全方位的诊断云原生业务应用综合成熟度的水平，并结合弹性高、可用、自愈、可观测和自动化等五大云原生应用特性的成熟度。从业务应用视角为项目团队指引能力提升方向，更好的匹配业务应用发展需求。这里也设计了这样五个级别，首先看初始级，初始级就是业务架构完全没有云化，并且完全基于单体的应用架构；再往上是基础级，具备了架构机的弹性，基于分布式应用架构应用服务，具备有限的弹性和容灾能力；第三级是全面级，应用架构孵化改造开始，应用具备一定的弹性和高可用，实现多维度的应用监控。再往上是优秀级，应用架构服务化改造基本完成，充分享受原生生态，应用具备弹性，高可用，基本实现服务自愈，可观测性以及自动化应用架构；再往上是卓越级，应用架构持续演进，应用全面实现弹性，高可用服务之余可观测性以及自动化和智能化交付。可以看到经过这样的五级的评测，能够一级一级的把企业客户的业务应用成熟度很好的做评价。四、云原生业务应用成熟度（CNMM-TAS）1.云原生安全挑战和发展趋势最后介绍一下云原生架构安全成熟度模型相关的情况。接下里一起来解读本次信通院的云原生架构安全程度标准。整个解读分为几部分，首先介绍云原生安全性挑战，以及在国内外的发展趋势；接着介绍信通院在云原生安全标准化工作的引进，以及此次标准模型和在五个标准大域下的细分解读；最后介绍阿里云在本次测评的结果，以及友商对比的展示。随着云原生技术架构的成熟，在企业应用进行云原生化改造的同时，安全问题也随之而出，基于传统的基于边界以及信任域的安全架构已经不适用于云原生环境，同时应用侧的容器形态也为架构带来了更多的攻击面、敏捷、弹性等云原生特征，对传统安全技术也带来了新的挑战。为此无论是云原生服务商还是企业用户，都迫切的需要构建自身云原生的安全防护体系。在国内信通院也是最早的一批关注并且投入到云原生安全调研的权威的研究机构。在信通院今年关于云生用户的调查报告显示，大部分的企业用户已经认识到了云生安全能力建设的重要性，而安全性尤其是容器和微服务相关安全问题，也连续两年成为了企业客户在云上关切的最为核心的关键问题。在海外以原生安全为背景的安全防护实践已经经过了一段时间的积累。可以看到除了政府层面的回归标准的发布外，企业在云上的安全预算也在逐年递增，据 Paloalto 今年的云原生安全调查报告显示，今年企业在安全上的投入占比会超过整个企业在云上预算的20%。在企业对云原生安全迫切需求的前提下，以云原生安全为背景，也涌现了大量优秀的开源项目，也可能 CNCF 在社区也出现了很多安全相关的优秀的开源项目，像 falco 这样的项目在业界有相应的知名度。另外 CNCF 也会在今年发布VR版本的云原生安全代理数。2.信通院云原生安全标准化研究持续推进通过上面对云原生的挑战和趋势的分析，可以看到尤其在国内需要一个权威机构定制专业化的安全标准，来帮助、指导和规范云服务商和企业客户，构建云原生环境下全方位、端到端的安全防护体系。下面介绍一下云原生安全标准化工作的历史演进，在2019年基于容器平台的安全能力要求立项，阿里云就是首批参与标准定制并且首次通过测评的服务商，2020年10月信通院主办的云生产业大会上，阿里云、华为、腾讯以及主要的一些安全厂商作为首批成员成立了云生安全工作组，从20年4月开始，信通院联合业界20余家单位的近40名专家，历时一年完成了国内首个云原生安全成熟度模型标准的编纂，为企业云原生安全能力建设提供了自检标志和检查指南。同年，信通院联合十八家企业发布了云原生架构安全白皮书，阿里云也全程参与了白皮书的研讨和定制流程。3.云原生架构安全能力成熟度评估模型这里首先来了解一下此次云原生架构安全能力成熟度的评估模型。首先在分级的评估方法上和架构的程度标准类似，总的评级分为五级，分级的目标是力求做到差异化的分析，以及多维度把脉的要求。其中卓越级的标准，也就是 L5的标准是力求为云服务商在云原生安全能力建设的后续上提供明确的指导方向。优秀级标准就是 L4标准，全面包含了当前各服务商所具备的相当优秀的一些产品化的安全能力，来帮助运输商在整个测评的过程中，通过差异化的比较来发现自身的不足，整个标准体系涵盖了五大能力域。包括基础设施安全，基础架构安全，应用安全，研发运营安全，以及安全运维五大能力域。15个能力子项，46个实践项以及近400个细分能力的要求，本次阿里云也参与了所有五大能力域的所有细分子项的评测。下图表格是关于此次标准五大能力域下，各个能力子项的细分实践项的展示，也可以看到表格中涵盖了非常多的云原生安全相关的产品化能力，投入本次评测的阿里云的服务也非常多。包括容器服务及镜像服务，云安全中心，外部应用防火墙等20余款的云原生产品。全方位的考察了阿里云在云原生产品安全能力上的丰富度。另外本次考察的力度也非常细，除了中国信通院工程师严格执行标准的验证以及细致的考核外，所有的测试项均是基于阿里云的生产环节完成。最终的评测报告也达到了将近400页，下面开始五大能力域的一些细分的解读。（1）基础设施安全域首先是基础设施安全域，阿里云在计算、存储、网络等云基础设施上构建了非常坚实的平台，底座的安全能力。在计算安全方向，云安全中心和容器镜像服务来支持漏洞自动化的检测，告警溯源以及攻击的分析，同时也支持镜像漏洞的自动化智能修复能力，同时还支持像多 OS，混合云架构的机械扫描，以及丰富的策略配置能力。在网络安全方向，云防火墙服务支持多重的边界防护，以及基于流量学习结果的自适应的智能策略推荐下发的能力。在存储安全方向，容器服务的备份中心可以支持应用数据异地备份以及快速恢复，而 ACK 也提供了多元混合云场景下的这种两地三中心的备份容灾能力。同时 ACK 还支持基于软硬一体的机密计算技术，来帮助实现内存维度的剩余信息的保护。（2）云原生基础架构安全域下面是云原生技术架构的安全域，首先在云原声的网络侧，容器服务和云安全中心提供了 pod 维度的东西向的策略控制以及智能阻断的能力。同时还支持集群网络拓扑的可视化的展示。而 ASM 网络服务也提供了思维 space 框架下的全链路的流量加密，观测监控以及七层的访问控制能力，在编排和组建安全方向 ACK 容器服务，可以支持多维度自动化的安全巡检能力，帮助发现集群应用潜在的风险，并提供加固的建议。使用托管的节点池还可以实现集群节点 CVE 的自动化的自愈修复能力，同时在访问控制上 ACK 的 RSA 功能还可以支持集群应用测 pod 维度的云上资源的全线隔离。在整个镜像安全方向 ACR 容器镜像服务的企业版，提供了云原生的交付链功能，可以结合镜像的完整性校验等产品化能力，构建企业级的供应链 desktops 能力，在运势安全方向，云安全中心可以支持容器维度的 runtime 的危险实时检测告警，以及智能处理来帮助企业抵御容器逃逸，像敏感文件、操作、异常连接等多种容器内的攻击的行为。（3）云原生应用安全域下面是云原生应用安全域，云原生的应用安全也包含了企业应用测防护的方方面面，可以使用云防火墙和外部应用防火墙等服务，来实现企业应用南北向以及东西向的攻击防护和吸力力度的防控控制。同时也支持 API 漏洞，包括注入攻击和敏感数据泄露的检测分析以及自动修复的建议。同时企业应用还可以接入 arms 的 rough 服务来实现 API 维度的调用链接控以及 API 服务资产管理。在微服务安全方向，MSE 微服务引擎可以通过云原生的网关，结合云防火墙等服务来保证微服务网络通信的安全，同时在提供丰富的微服务治理能力的同时，也提供安全监控以及应用代码层的 RAS 服的防护能力。在 serverless 安全方向，函数计算符支持存储网络等函数资源的吸力度的防控制和租户隔离，同时还支持函数资源流量的实时监控以及完备的审计。（4）云原生研发运营安全域&安全运维域最后来看云原生研发运营安全域以及安全运维域的情况。首先是研发运营域的情况，阿里云的安全团队对平台内部的研发运营流程有严格的安全审计和管理。包括对云产品的定制化的需求管理，以及对制品安全的自动化扫描，完整性校验以及身份溯源。在安全设计上，也支持系统化的维权建模，以及内部标准化的安全设计规范和相应的技术站。在测试安全方向，内部也有完善的 def sex of 流程来实现，无需人工干预的封建识别以及运营。云原生应用如何经营安全运维也是企业关心的重点问题，在安全管理方向，容器服务和云安全中心等服务都支持非常丰富的一种云原生，可视化资产管理的能力。同时基于日志服务，也提供了管控测和业务测的完备的审计日志，并且支持基于审计的智能分析告警以及图表化的展示能力。在策略管理上，容器服务知识基于 ops 的集群部署时刻的策略治理引擎，同时云效服务也针对云原生开发测试流程，也提供了基于策略的运营流程配置以及相应的安全检测功能。在安全运营，云安全中心只是通过云蜜罐诱导来捕获攻击者，并且实现这种自定义的攻击反制，同时还支持多维度可视化的监测预警以及溯源分析能力。另外自身的阿里云威胁情报平台，也可以通过多种渠道来进行漏洞情报的获取，来帮助企业安全运维团队提升整体的运营管理效率（5）评测结果最后本次评测的结果，阿里云在此次标准所有五个域的测评中，都取得了国内唯一的全域最高等级认证，下面表格也展示了首批通过此次云原生安全成熟度标准的企业关于本次测评的完整的测试用例，以及检测报告。
-
发表了文章 2022-11-24
BizDevOps：数字化转型浪潮下技术破局之路 | 学习笔记
开发者学堂课程【BizDevOps - 数字化转型浪潮下技术破局之路：BizDevOps：数字化转型浪潮下技术破局之路】学习笔记，与课程紧密连接，让用户快速学习知识。课程地址：https://developer.aliyun.com/learning/course/1076/detail/15549BizDevOps：数字化转型浪潮下技术破局之路BizDevOps：数字化转型浪潮下技术破局之路2021年阿里云开发者社区推出了乘风者计划，1500名技术博主入驻社区分享技术实训与思考。不久前，乘风者与名校合作，推出了DevOps评测大赛，收到了不少企业一线开发者宝贵的肯定与反馈。在大赛的过程中我们也深切的感受到Devops作为全球IT组织基于惊异敏捷思想的方式得到了不少在数字化转型过程中企业和机构的认可。然而在数字化转型浪潮下，devops也同时深陷如何发展的问题，如何让IT组织不再成为被诟病的中心而是成为效率中心或者创新引擎成为全球IT组织所面临的重大难题。本节通过分享带领大家找寻如何推进业务发展的答案。本次论坛的副标题开宗明义，提到数字化。我们是一个数字化时代，所以我们在谈bizdevops。该热词冒出后我们在银保监和人行在今年年初时发布了金融科技和数字化转型，属于银行和保险行业。但是其中已经指出我们在数字化时代要做到业绩融合，同时也指出了我们要做bizdevops。时代背景下的感受，如何看待大环境，如何看待科技的发展和业绩融合？转型工程一方面让自己选择了业务架构的专业方向，另一方面让我体会到在银行业中或者一些传统企业中，如果我们真的想通过一次企业级的工程去整理提升我们的业务和技术能力，并且实现业务和技术的融合，确实是一件困难的事情，需要有一些方法指导。此外也有可能企业推动力不强。但是现在我们处于一个很大的背景，即国家提倡数字化转型，从十四五规划到2035年目标的开启，包括今年出的数字发展规划，为全社会都提供了一个数字化转型的愿景。并且转型是以数据要素为核心，产生一个新的生产要素，通过这个新的生产要素，我们就有了新的生产工具，也就是软件。或者是说把原来这个软件做进一步的提升，让这个软件加工数据能产生更大的商业价值，然后再通过网络这种方式让整个社会协同起来，变成一个完整的数字化转型。这种国家大政策的背景指导下才有了我们说的产业数字化里的银行业这两个指导文件，一个是央行的金融科技发展规划，2020到2025；另一个是银保监会的数字化转型的指导意见。这两个文件分别从这个行业的宏观角度，以及对金融机构的具体要求的角度，提出数字化转型的方法，并且也带来一定的具体要求，所以它变成了一个行业的一个转型的一个参照，或者是一个指导。其中，央行比较侧重关于产业的整体提升，其中也提到了bizdevops词，它是放在产品及流程服务改进该方面的，相当于数字服务方面，此方面除了bizdevops外还提到了mvp：我们常说的敏捷中传送的词，它有一个比较高的要求，希望我们的业务系统或者业务创新能够实现跨流程的自由编排和组合。该要求很高，对于互联网企业来讲也很高，所以需要一些新的方法论，新的工具去集成。这种转型慢慢偏向整体转型，将两份文件综合起来读，其实能看到这两份文件为银行的数字化转型画了一个大的范围图。阿里中的一篇文章从架构视角解读这两份指导文件，提到从房顶的角度来讲，要求所有的银行做好数字化转型的战略，在考核方面做好支撑，这是管理层面。往下是实现层面，会提到两个支柱，分别是技术能力（一个银行自己在技术方面要达到什么水平，自己哪些技术一定要掌握）和生态能力（需要有人提供其他部分）。业务方面其实也要有生态，因为银行只有金融业务，但是如何想做其它拓展就需要有生态。有了技术能力和技术生态，两个中间还需要有架构能力，能让这些技术组合起来发挥作用。这两个文件也从两个不同的侧面提到架构问题，一个从总台的角度，一个从企业级已有平台角度都是新的挑战。如果想要实现架构，还需要相应的人才，无论是业绩型人才还是专业架构人才，有了这些人和架构的管理才能将数据作为一种新的要素，作为一种能量迸发出来，之后流向后台，即数字经营、封控，包括组织经营一些绩效的考核。前台就是数字服务，需要打破数字鸿沟，创新新服务类型。这些都需要我们有一个体系化的集成，这就是我们需要找的东西。以上仅仅从一个行业，该行业包括中国金融行业，包括中国的银行，实际上在信息化和数字化走得很前，所以我们把一个宏大的趋势展开了，以上讲的内容实际上是有bizdevops的。如何看待未来的发展？阿里巴巴发展多年都离不开技术去支撑技术的发展，所以说阿里一直在提技术创造新商业这个词，可见技术对整个商业的支撑是非常有利的，而且，互联网以及金融天然就是一个数字化的一个行业。在该背景下，阿里在这方面也遇到了很多挑战以及做了相应的应对。在很早以前，阿里其实面对的是如何将技术去进行一些自动化，去进行一些提效相关的一些工作，那个阶段我们提出的一个口号是技术中台，也就是用的一系列的工具，自动化的平台，去将在技术角色里面的一些能力和效率进行提升。也就是大家比较耳熟能详的敏捷开发、devops，然后我们就通过一系列的工具去将大家整体的能力和流程标准化到这个平台上，然后最终形成了让整个集团的数万名员工整齐划一的去工作，这是第一阶段。到了第二阶段时，我们遇到的问题实际上就是整个业务层去支撑业务如何能够更加高效，这个时候集团就提出了业务中台以及数据中台等这些概念。此时除了原来devops的部分，会发现所有的技术都要往业务靠近，即通过业务中台的方式。此外去建立了这个业务跟技术之间的一些通道。到最近两年，这方面又发生了一些变化，是因为最近在提一些高质量发展，包括一些战略执行，包括各方面，从阿里的角度来讲，希望在顶层的一些战略可以顺利的逐级的去传达到下面的业务和技术团队，让大家在人力分配上，以及战略执行上，或者产品和项目组织上会更加高效。所以说整个集团又特别的在意整体的业务和技术的协同方面，现在我们也在讨论如何去通过一些方法和工具，能够将这个技术团队跟业务团队之间的协同形成统一化的一个方法流程，然后最终能够落地到这个工具上，形成一个标准化的模式，然后来提升效率。以上展开了三个阶段，非常适合行业中进行学习。第一个阶段仅仅是向技术要效能，即技术技术要做得好；第二个阶段，实际上已经不仅要从技术要效能。此时阿里造了一个新词：中台。支持业务这件事实际上也是在支撑能力，为业务带来创收。最后大家追求的包括上述为什么一直在提的bizdevops，实际上是要要求去创新，去引领市场，创造新的这个数字化商业模式。从大学教育角度的思考或者顺应这种思考看到的契机是什么？最早我们开始这个课程是从2017年开始，配套这个课程后面又建设了慕课，然后又有国内的第一本中文devops教材。今年我们和全国标准化信息技术标准化委员会制定出来的研发运维一体化成熟度模型国家标准，刚刚发布。所有这些实际上都是以学术角度来推进devops在中国的发展。整个大的一个市场实际上是在全面进行数字化信息化的这样一个转型，国家现在也在倡导数字经济。在这样的大环境下，我们在从实体的经济或者说是物理世界逐渐地向数字世界向信息化世界来进行迁移，属于一个移民的过程。在这个过程中我们看到在未来可能所有的实体经济包括一些服务业都需要做数字化，在某种程度上未来都会变成软件企业。可能我们自己不做，但是阿里会帮你做，美团会帮我们做。所以在这样一个趋势下，我们要把这些业务数字化。数字化的引擎是软件，数字化给软件的所谓的引擎的燃料是数据。如何看待该趋势？作为一线架构师，对开发者来讲其实他理想的情况是做事情的时候能够足够专注，能够不被打扰，能够聚焦在要做的事情上。但是事实上我们发现在还没有讲devops而是特殊自动化、持续集成前，都是在解决开发测的事情，即我们如何更高效的开发如何高效测试如何更高效的去集成发布。但是那时大家有一种问题：做的很快但是不一定正确。我们团队很小但是我怎么样保证我做的是对的事情呢？就是一周只做一件事。小团队可以，但是放到阿里的大团队上不可能做该限制，那么如何聚焦到做正确的事呢？这对开发者是一个很大的挑战。思考如何与前面的业务进行联通，确保做的是一件正确的事。另外一个特点：软件的研发虽然越来越发展，但是从比例上讲真正在底层研发的人比例越来越少，大家往往做的事情是偏向支撑业务。此时软件研发的方式和习惯也在发生变化，所以不是像以前做一个通用的数据库，而是要围绕业务需求去演进，这对一些开发者来说也是很大的挑战。由于我本身是在做devops工具，所以就要思考自身做的devops工具如果做的足够好是否可以帮助到一线同学可以运用这种工具来提升他们的幸福感，提升他们整体的交付效率。将上述两种观点融合可以推论：任何企业未来都是一个软件的企业，每个人都会成为开发者，而开发者体验就是非常关键的。从另外一个角度，从就业者的角度，我们今天讨论的话题是有意义的。如何看待这种挑战？从数字化的角度来看刚刚说的金融行业的确是走在数字化的前沿，因为它的信息化可能就在前面。但是最近的确看到一系列行业，那些真正开始尝鲜的人，已经享受到了数字化的红利。数字化在我们以前做工业时代就是流水线。我们能够把质量和效率这两个统一起来，我们做生产线既得到质量也得到了效率，而不是以前的慢工出细活。但他一定程度上牺牲了个性化的体验。例如福特说的：你可以要任何颜色的车只要它是黑色的。它是以规模化和标准化为前提，得到了效率和质量。但是数字化第一次让我们把个性化的体验拉回来，效率、质量、个性化体验同时得到。今年产能是过剩的，而我们对美好生活的追求对于个性化追求越来越多。所以谁能第一个掌握该技术，效率、质量和个性化体验都能得到，只有数字化才有可能。所以此时很多我们已经看到的一系列企业无论是在物流领域还是房产领域等都通过数字化的方式将这个时代抛在了后面。所以这句话：未来任何一个企业都是一个软件企业，或者说未来任何业务你要想有竞争力，就必须运行在数字化的基座之上。既然运行在数字化基座之上，对于你的业务的创新和发展，那就需要在这个数字化基座的本身这个软件上迭代和调整。所以这对于我们软件的开发，提出了非常高的要求，比如怎么能够拉通端到端的全链路的观看而不是只看产品，怎么建立本质的数字化模型。上述讲的从物理世界过渡到数字世界，而且还要反过来去影响真正的物理世界，那么对于该事情的本质认知、模型建立要求就会更高。还要交付模式：交付的快慢、交付的精准性，直接影响业务迭代、业务创新的效率效果，这也是我们本节讲devops本身的一个大背景。以上讲到了非常关键的一点：质量和效率。每个行业都有追求，现在又加了一个维度：个性化体验。这是一个核心的数字化会给各个企业、各个产业、各个行业会带来同样的挑战。同样也是一个机会，抓住就能够成为数字化时代的佼佼者。数字化天然可以解决这些问题，从用户需求的获取、还原，基于还原需求的设计、生产，再去交付服务。如果没有数字化的支撑，是不可能在整个环节中做到个性化体验的难度。回到这次论坛的主题：bizdevops。Devops已经成为软件工程行业的主流，那么外界会是什么感受呢？我以前做的软件企业或者项目事实上都在做一些技术性的软件，不存在一个明确的业务方和软件隔离，它们都是技术性内容。但是在阿里后确实有一个明确的业务，会发现作为技术人员来讲不希望被当成一个资源在技术方面做事，是可以为该业务创造一些价值的。事实上希望业务和技术合作完成最后的业务。合作关系不是业务主导或者产品主导，是一个共生合作关系。现在偏零售或者金融这种行业有非常明显的一个特点。在这种情况下对于一线的开发者来讲有一个要求，同时也有一个感受能知道这种现象的发生，对他们来讲更重要的是如何更好的融入到这种变化中，这个变化对于我现在有什么影响，该做什么事情融入这个变化。这就是我们的工具该帮助他解决的问题。现在很多的开发团队实际上非常欢迎提出这种概念，因为他们日常已经在做这种事情。他们受到业务的反馈，如果做的事情不好，不是业务想要的，那么得到的反馈就是负面的，会被业务推着走。此时作为积极的开发者来讲，当然希望往前走一步，跟他更紧密的结合在一起，互相将结果拿到，这是一个很好的现象。阿里起源就是在互联网时代，所以阿里的机遇是存在的。从业务层看待该事情，对该概念会有什么反应？从业务角度来讲，例如像银行，业务占绝大多数，90%都是业务人员。在这样一个环境下业务会有蓬勃的需求。但是有些银行的层级比较多，实际上产生业务需求的人比较底层，他的需求逐级反映上来后已经存在了衰减。即我们满足了很多的业务需求，但还有更多的业务需求没有满足，如果有一种业务研发一体化的方式，能够支撑我们快速的响应前台的需要，那么对于一线人员的支持会很大。在很多银行中数据的应用有可能在中层管理以上，因为它是通过报表的形式来使用的，像一线经营时，目前可能有一些关于精准营销或交叉营销的推送。但是真正一线业务人员中使用数据的需求，我们的挖掘是不足够的。需要我们的研发体系可以更快的相应需求往下沉，这样对于客户来讲才是更好的。更重要的一点，今天我们所说的很多软件或提到的一些名词例如业务架构，很多人不能理解，那么能否有一套更好的展示方式能够让我们直观的看到这些功能，例如像我们今天的rpa，其实不是一个很复杂的技术，但是能够让业务人员学会怎么拼一个流程、现场就能采集数据，这是我们所希望看到的。是否有这样的工具和平台或者研发体系能够将我们后台对于业务人员来讲等同于黑盒的内容白盒化的展示给前面，将业务与技术结合起来。以上从一个业务的角度（业务是务实的，例如要完成一个api，如果可以让我更快的完成这件事情，提出这个概念还是很欢迎的）另外一个角度业务影响指导（现在的业务随着一代一代的人在数字化时代里生活，其实也想了解软件是怎么来的、如何开发的）。中台与bizdevops有关系吗？上述提到了两大类问题，第一大类问题其实是一种协同的问题。现在以一个中台的例子讲解一下协同的问题。其实中台是一个大的部门，需要支撑很多业务线，有大的业务线，有小的业务线，需求从业务人员处反馈的就非常多。此时就存在一个问题：需求从最开始的业务人员基层开始反馈，一直上升到上面的业务设计人员，再从前台的部门传递到后台的部门，其中就有非常多层次的衰减。然后还有优先级的问题，到了中台后无法判断哪一个优先级更加重要，这是一个典型大型企业的协同问题。就是因为这种协调问题的梳理不通，没有一个标准化的类似于我们提出的bizdevops这样的方法理念就会很混乱，混乱就会导致很多有价值的创新的想法最终没有得到真正的关注。甚至是高层想要投入一定资源做的事情，到了基层可能也没有投入足够的人员去反馈。另外一个是如果今天不让技术成为瓶颈，不让中台成为瓶颈，开发一些新的东西让业务同学自己做，包括rpa、中台，在中台上尝试搭建一些业务流程，将中台的组件组成一些流水化的内容，让业务人员直接编排配置。不需要再找技术人员，直接在上面用一个流程化的东西去配置。这样的工具也可以解决bizdevops，业务人员和开发人员之间的协同问题，让创新更快的发生。无论是在协同方法上改进，还是直接左移的方式技术的方式去改进，都是想让一些有价值的业务创新可以得到最快速度的响应。在谈中台时，很多时候还是由技术部门发起，发起的要点是科技师可以往前站一站，找到一些业务能力的提取，能保证在业务发展的过程中可以产生一些作用。甚至有一些不同的组合，一些业务的支撑的创新。当我们在提bizdevops时，它在牵引着我们的方向。中台这样长期运作下去，甚至于会产生阻碍创新的影响。因为是按照自己的优先级选择，并没有考虑业务的优先级，所以这就出现了一个新的弊端。bizdevops开展为计算机类专业课程，如果将课程改为bizdevops会对软件工程的学生有什么影响？这种跨学科跨专业的融合已经在大学中出现，我们的计算机类的课程不仅仅是服务于本专业的学科。很多其他院系都会将计算机能力变成一个通修课程，并不只是在计算机类和IT领域。无论选择哪个专业，计算机能力可能都会成为一个必备的知识。尤其对于软件学院，开放了devops课程，还开发了敏捷课程，而且也有创新创业的课程。所以我们软件工程院系与计算机院系的不同是更面向于实践，更面向于工程，更面向于交付的价值。Devops在做工具或者做产业或者是做推广或者是在学校，虽然说得到很大的认可，但是该运动还没有结束，仍然在往前发展。在该运动过程中，devops运动中哪些是可以借鉴的，哪些是应该避免的？Devops运动是在2009年左右提出，要打破dev和ops之间的墙。今天来看都属于IT或者技术部门，在业务角度看两者融合。但是事实上在当时两者之间的距离很明显，因为它们的关注点和目标不同，dev目标是快，敏捷运动，关注的对象是代码，ops目标是稳，关注的对象是机器。目标上有矛盾，关注的对象不同，所以devops运动提出后首先目标是要同一目标，要更快，其实也是对于业务或者客户需求的响应。产生了一些非常好的管理方法是打通了整个层到ops层的流程，借鉴了一些精益的方法，这点非常重要，借鉴了当时敏捷开发的方法，讲究端到端的流程以及反馈。这一点在协作上面非常好，但是最终要落到技术上。落到技术上后，一个关注代码，一个关注机器，最终关注的都是应用。包括应用的代码、配置、环境、数据等甚至是流程，所以以应用为中心去开发。这成为最后阿里和微软指定共同推进的om标准，开放应用模型，将开发和运维人员关注的视角进行统一。看到了两点，既要有理念和方法上的改变，但最终还是要有技术上的手段来解决，这是要借鉴的。对于bizdevops，要统一目标，所以业务和开发共同的目标是什么，这时我们需要思考的，如何让业务和开发在一个目标下进行工作。第二个我们在流程中有什么共同关注的东西，例如在devops中有共同关注的应用，而现在应该关注的是价值的交付。所以从bizdevops的目标来看，很有可能是如何打通业务、开发、运维、工程等的职能，能够实现业务价值的快速交付，形成一个有效的闭环，在数字经济情况下更有效的支撑业务的发展和激发业务的创新。所以共同的目标找到共同的关注，最后再落到有效的技术或工程实践上，是我们要做的事情。总体上bizdevops是非常成功的，所以从借鉴的角度，bizdevops的智能扩展打破IT内部的墙的情况下，今天更重要的是打破IT和业务之间的墙，但要做的事情很多。上述总体比较认可，如果将devops看作数字化时代的变革是比较成功的。该变革关注了两个原来利益不同方的共同目标，如何将价值拉通，最后形成一套有效的方法文件工具。该变革的模式放到今天bizdevops往前走有一定指导文件。业务也领导很多devops，不仅仅是银行，其它很多产业也引导，那么业务侧理解下bizdevops有什么可以借鉴的？首先大家要统一目标，其实企业中很多时候有一些有形或无形的墙存在，但是从墙的角度来讲，墙本身也是合理的。因为企业内部是分工协作的，既然要分工，肯定会产生专业化的内容。专业化会产生知识壁垒，自然就会有一道墙存在。技术内部有一些墙要弱化让技术统一起来或者协调起来，其实在业务侧也一样。在业务层例如在银行条限稍微有点分割，但是这么多条限，大体上服务的客户是一样的。零售的条件都是服务那些个人客户，对公的条件都是服务那些公司客户。但是不同的部门其实对的客户是一样的。有这些分工，按理说也要协作，也要往一起走。但如何将业务侧打通，但是现在又不仅是业务侧打通的问题，因为我们现在这个社会的需求变化快，客户不止接触银行，接触很多行业。有的人别的行业带来一些变化会让他的业务形态产生一些改变，这个业务形态的改变有可能跟银行协作时就会不同。这两年，电商拉起的销售的支付频率就相当于要求银行支付效率也上升，业务处理能力也上升，那这些就从业务侧传到了技术侧。希望整个都能协同起来，我们希望能把这个东西传导好，能打通这个壁垒。但是业务间就有隔离，业务之间要统一自己内部语言。要先把自己统一起来，就有点难度。其实业务侧不是一点模型化思维都没有。例如银行的一个特点，我们发新产品之前要发制度，制度里带有流程图，所以它本身有这个流程化和结构化的思维，但是不同的部门画的的标准是不一样的，所以我们可以先通过一些业务模型的方式，让各个部门去描述自己流程的语法一样，这样业务内部语言统一后再跟IT对话时，大家都用相同的方式去表述流程，包括更重要的是用相同的视角或者定义去看数据，把数据和业务这两个东西统一起来。这样IT这一侧才不会项目组跟这个部门打交道，对这个数据和这个业务是某一种认知，换了另一个项目组，跟另外一个部门打交道的时候，相同的数据两边定义的不一样，然后到报表上一合成时就出问题。所以要想把业务到biz再到dev再到ops统一，语言是很重要的。但语言不是单一一个方法论一下子就可以解决掉的。从一个基础语法到一个长期熟练使用的语法，这样统一建立起来。这样从biz到dev到ops之间就可以更好的进行关联，当然之后还离不开企业内部的标准化问题。需要自己定业务标准，定数据标准，定义好这些标准后还得扩展到行业级别。同一级行业或者上下级衔接的行业都要互相之间定义好，有了这些标准化，整合起来还需要一些时间。上述第三次提到很关键的一个词：数据。在开展包括devops相关课程时如何看待接下来的数据和我们工程实现的一个关心？如果我们将使用生产关系生产力进行比喻，在现在全面数字化的时代，对于我们软件行业来说，devops实际上代表的是软件行业第一生产力。与此相关的数据就是生产力下的生产资料。因为所有的软件实际上都是要进行处理、输入数据然后产出数据。这些数据实际上变成了驱动各种业务的力量。以上讲述的将biz与devops进行结合，可能在biz方面需要做很多的支撑工作，如果导入bizdevops这可能是我们前期的一个目标。devops本身已经发展了很多年，相对来说比较成熟，现在已经变成了一个我们来快速进行迭代、进行发布、进行试错的实验系统，已经使企业有了这样一个能力。以前没有devops时做不到该点，只能通过其它方式来解决业务的需求例如创新的问题。但如果我们有了这样一个系统，biz就可以利用该系统然后让它能够更快的响应市场需求，响应用户变化。这还是一个阶段，但是再往后发展，例如我们将biz放在devops前，再往后我们就可以将biz放在devops后即devopsbiz。它的立意是我们后面所有的创新实际上必须有数据支撑。现在遇到的很多问题是数据整体流通的环节比较多，决策的周期非常长。但是如果我们能够打通这个数据，那么我们就有充分的证据例如领导管理层就会更有信心的支撑我们的创新。以上讲述的三个单词不应该放在一条线上，而是放在一个环中。我们最后在看数字化时代，如果我们加入数据生产要素后实际上产生更快甚至某种意义上以实验的精神来创造一些商业机会的。这个环节讨论的是devops运动可能还在继续，这个过程有些艰辛。特斯拉一个经典的言论：“比起造汽车来说，设计这条流水线的难度是它的一百倍”。对于做平台和做工具的开发人员来讲正在做这条流水线，按照上述讨论的devops还未支撑好，现在使用bizdevops，会有什么感受？觉得平台和工具未来的走向是什么？觉得哪些是可以从bizdevops学习到的，展望bizdevops工具和平台如何做才能够将流水线做出来？我们其实是从数据的角度来看是否可以做到商业的成功的。现在做的devops产品，本质上也是一个业务，服务的群体是一线研发工作者。在这种情况下，我们也要将它的整个数字化体系建立起来。但是事实上经过很多年的发展市面上有很多工具，大家往往真正在企业中做该事情时还是想办法再建立一个系统。这个原因我们也在思考，发现大家在一个真正能够用的流程上能够将它做下来还是有很多要求。首先，是能够将整个数据模型建立起来的，该数据模型在各个工具中往往是不予批的。所以我们需要有一个共同的理解，保证业务说的模型与技术说的模型一致，这是一件很困难的事情。不同的人对于应用的理解不同，更不用说建立起一个数据模型将互相联系连接起来。有两方面需要努力的，一个是如何形成一个相对大家通行的规范，例如云原生逐渐有一个标准，但是devops目前还没有形成，正在形成该过程。另一个是devops的特点是将不同的人不同的角色协作起来，有没有一个统一的视角。上述也提到作为一个研发角色，或者作为测试角色经常被打扰。要与另一个人去同步一个信息或者需要询问一个信息，这件事情是非常影响工作效率的，也是数字化非常忌讳的一件事情。所以devops作为一个工具来讲如何提供多个角色作为一个统一视角，即我们现在是否可以进入一个应用视角，那么应用与协作之间工程与协作之间是否可以基于价值去连接，这是我们应该为之努力的。以上两点中很重要的一点是，本身这个流水线就是有客户的，有多个客户。并且建立流水线时核心的逻辑不是流水线的供应而是它背后的数字模型。从另一个角度来讲，现在也服务了很多客户。在服务客户的过程中发现，大家对devops科技部门工程师要做的事如何做是比较达成共识的。采用一个一体化的研发云平台，要走向云原生，甚至要建立流水线，建立这样一个标准模型，大家已经逐步形成共识。因为我们看到整个标准和方法实践都是在收敛的，收敛后做的工具相对来说很容易进行标准化，去适应开发者对工具的需求。这样工具就可以适配它的研发流程，大家有意愿将原来的工作模式迁移到新的方式上。在这个领域已经达成了共识，包括在金融行业，基本上都是要采购一体化的平台。但是我们进去后发现也只是相关的科技部门，对于业务部门影响力不够，但是发现只是解决这部分工程师的效率问题，其实很难改变该企业本身的业务创新性问题以及业务的交付效率问题，所以我们也在尝试与这些企业去讨论如何实现bizdevops面向业务价值或者面向业务成功的流程。但是在讨论这个流程的过程中发现大家从来没想过可能没想过通，但我们一想以后觉得确实是需要通。那么如何通？业务人员跟技术人员之间的对话的语言体系是没对齐的，甚至业务人员他本身可能团队比如说以产品为中心。为什么要以产品为中心，产品是什么？都没有提到。但一个产品下面是要建立多个交付团队，交付团队为一个产品负责他的职责流程如何去划分，其实不管是组织流程或者大家对于日志流程的概念，其实都没有形成一个共识。如果没有形成共识，那么工具上实际上很难去支撑它标准化的。所以也是大家需要思考的问题：devops如何在一些概念或者流程上能够逐步化的标准和收敛。以上提到了很重要的一点，就是我们会看到一些比较有创新力的公司，不一定是初创公司，包括大家看到微软的起死回生，前几年就是彻底大转型。他们当时的工作方式发生了一个变化。当我们在谈这个词语的时候，很多人可能会觉得比较陌生。我们稍微畅想一下，bizdevops往前看一看，如果这件事情我们推下去了，或者这件事情发生了，在工作方式上对一个组织，一个大的企业，或者我们一个团队最大的工作方式的变化是什么？我觉得最大的工作方式的变化一个是与我们数字化转型方向的结合。首先是业务侧，当真的开始觉得数据有很大价值，然后也真的开始需要使用这个数据了，那么就需要去定义这个数据。那么从定义数据的角度来看，它原有的这种稍微模糊一点的工作方式就要变成比较精确的工作，这样才能去给数据下一个好的定义。同时，我们也都知道数据其实是模式化的，它并不只是说一个词是什么意思，它应该说的是若干个属性加在一起所描述的业务对象是什么。而且该业务对象，我们也知道根治上来讲是业务而不是技术人员。所以从这个角度来讲，如果业务人员觉得数据有用就开始精准的去定义它，那么就会开始用数据驱动自己的业务。那么整个业务工作的流程的变化，或者说自身的创新，其实一定程度上都是来自于数据。我需要用这种方式重新看我的业务创新，业务创新并不仅仅是想个点子，写个字。而是我的业务创新本身就带着一定的数字化实现。即天然就需要业务和技术是一体的，我需要思维方式上一致。统一语言后面反应其实是思维模式，思维模式决定你的元素和方式。那从这个角度来讲业绩融合这种工作方式或者是一同创新，通过这种共同创新来更好的发现数据的价值对我业务的一个提升和变化，这应该是所有企业的一个变化。像我们说的一切业务数字化一切数字业务化，天然就带着我们bizdevops这个想法在里面。真正有一天这个数据这个生产要素被我们发挥起来了成为了每个人日常生产或者是我们工作中的一部分的时候，就自然实现了。数据这个应用当然是我们的一个理想但是它是需要一些基础的。当我们看到在数据应用之前我们希望能看到什么东西，先从业务的角度来看，第一个它的视角会发生变化，在数字化转型下，业务的本身也存在一个条块之间的分割和墙，那么问题不能在问题本身的层面得到解决。所以必须跳出来看，只能站在将来的业务的设计或者业务的思考或者更多的是站在用户的市场，是打通整个用户需求被满足的价值链路来串通我们内部的业务流程，这是第一。那第二点在这个基础上，我们还要能够看到对于整体本质模型的深刻的认知，要建立起整个的一个数字化的模型。如果做到这两点的基础上，我们才能产生一个真正可用的数据，让可用的数据我们可以改成全量的，整个业务流程的数据都被记录，全要素就各个方面都会记录，还有实时这个数据不是候补的，而是在业务流程中就产生的全要素实时的数据。那么这个数据本身是中立的，数据产生一刻并不知道它应用场景，但是这时候我有了这些数据，那么这些数据的应用就是我们一些创新的机会。我们业务的人员有自己的场景，还有自己的目标，自然能激发他这些数据的应用。从业务角度看，从研发的产品，研发和业务的合作，我们看到一个自身产品研发也需要数据化转型，也要站在用户的视角，这里面的用户视角就是刚才讲的即我们做一个平台，它的用户是什么？是产品的研发，我们要打通站在这个价值交付的时间来去打通产品研发和和运维。我们自己研发过程中也会产生数据，所以在这里面有一个根本的变化。首先我们要从产品研发本身实现数字化转型才能更好的支持好整个大的业务整个社会的数字化转型。Devops在很多有一些这个组织中，科技高管会认为bizdevops本身就是科技的数字化转型，这是一部分。我们可以认为devops就是一个我们在整个企业甚至于说一个大型的机构中去数字化转型的抓手。其中有一个核心的一个矛盾点，就是我们怎么样才能改变业务的思考。科技这一侧实际上已经经历了一波，比如说之前包括敏捷在内都是一种工作方式的一个改变。在业务的情况下有什么想法，畅想一下我们怎么样才能把业务的工作方式发生变化？工作方式改变如果回顾devops的发展，最终促使他变化有两个要素。第一个是需求，从理念上去宣传。大家提出了这个需求，这个目标。第二个就是工具，不仅仅是软件平台包括方法建模方法等等，最终让这个事情变得可能。比如说我们现在在软件工程中有很多方法讲领域建模。我们有这样的一个使命就是要真的能让减少业务和技术之间沟通的鸿沟。所以这个在于我们需要一套这样的方法，如果DPD可能要向前，要用更多的用语言去梳理我们的业务流程，然后用业务的视角去表达出来。这还需要做很多工作，例如业务的架构和技术的架构如何更智能的过渡。目前在业内有一些进展，在需求的驱动下进展会更快的发生，这是讲建模。协作上如何真正做到业务驱动去协作，例如有一个业务的需求，有一个业务的目标怎么表达怎么分解为业务的策略和需求。业务的需求又如何分解到各个产品。分解完后，我们怎么为它提供一个在过程中还能看到它的整体的视图，当大家看到这些东西而且比较低成本的能用起来时，可能这个事情就更容易发生。工具平台是促进它的生产工艺的一个变化，生产工具的变化会造成很多事情的变化，比如生产关系、生产力的变化，甚至一些产品的一个变化。如果你有一个工具，可能别人会说我觉得不好用，你说的是错的，存在即合理，你需要适配我。遇到这个矛盾怎么处理呢？我们回到这个问题的初心上来说，我们做工具不是为了改变你而改变你，实际上是希望通过工具来帮助你达到某个状态，或者解决某个问题，所以我们的工具是来解决问题的。当然对于具人来讲，不能对你有太多的假设，对你现在的状态是没法假设的。我必须适配你在各种情况下的状态，但是我会给你指引一条未来状态的一条路，这是我们工具要做到的事情。所以可以从两方面来看，我们怎么去真正解决它的数字化的转型，它要利用数字化的技术来解决他商业上的成功，此时我要通过devops工具来帮助你达到这一点。这是我作为工具要解决的一点。另一方面，面对现在的现状必须有一条路径，这条路径能适配它现在当前的各种状态，而这个东西是工具不能假设的。工具一定是开放的，有实践和标准所承载的，有一定活性，但是还是需要坚守一些基本原则实践。今天我们提供这套工具，目的其实是帮助产业团队实现自身的数字化，这个是非常明确的。不管我们讲原来devops还是今天的bizdevops，其实都是来实现数字化，只不过我们现在讲述的数字化需要覆盖业务、技术、运维、测试等整个产业链的人员工作的数字化，这是我们的目标。然后再看现在很多企业现状，有非常多工具可以使用，这存在着一个最大的问题，就是这些工具实际上并不是能够完成最终这个企业需要数字化标准的工具，就是一些单点的内容，没有完全串联起来。今天我们讲bizdevops也是希望收敛该方法，能够收敛一些标准化的流程和实践，最终建立一个统一的流程的模型，该模型是企业数字化的根基。只要都在该流程上工作，那么产出的数据自然可以帮助企业去看清很多东西，例如每个重点业务目标的人员投入产出的效率以及它的整体过程。例子：今天业务人员很多，遇到了非常矛盾的事情，手里有十个需求，但是另一边只有几个开发，当提一个需求不能知道另一方在做什么，所以就会导致需求不再提出。但是今天如果能够让业务人员看到所有技术的工程活动与自身业务需求的关系。就可以做两件事：一是提效率不够，建议使之提效，另一个是可以在这里提升优先级，进行一个更合理的排期。但是最重要的是能够让大家用整个数字化的方式进行探讨而不是一个个独立，所以今天我们工具平台是将bizdevops理念做定义的方法或者实现该定义的模型能够进行串联，而它具备开放能力，可以兼容原来的工具。所以说如果我们的工具在企业落地，不是将它现在所有的东西全部推翻重造，而是建立原来缺失的流程的数字化部分，做一个补充。以上涉及到一个词改变。改变容易被抵制或者对抗。但是有一句话：人们从来抵制的不是改变，而是被改变。我们做的工具一定不是要求他改变的工具，而是帮助他去改变的工具。帮助他去改变肯定有一个我们与他形成共识的一个目标而不是直接修改行为。现在biz与devops、业务与科技之间很重要的问题是互相看不见，都不透明，都还是一个黑盒。如果我们现在能让他们互相都看见，我们能看见业务为什么要做这件事，业务知道我们说的需求达到了什么程度，什么时候有步骤一步步在往前走，这是一个巨大的进步。之前我们提测试和开发互相看见，又提开发与运维之间互相看见，今天我们提作为科技要与业务之间看见。之前所讨论的问题都是针对当下的问题，而对于高校，一个核心问题是解决真正意义上的认知和价值观问题。进了高校后得到第一个认知模型的建立，devops变成第一个程序去实践。知道这个理念的学生不需要工业层在再进行教学，当下需要解决的问题在在devops方面在这类大学生上是不存在的。这个经验放到BizDevOps上，对于mba的学生（学经贸或者是学传统经验上的物流、甚至是学历史专业、学文科、学新闻的学生、都是需要教授这种东西），对于这个有什么经验可以进行教授使得他们认为这个理念很重要？实际上考虑会有两拨人，一部分是业务人员，一部分是做传统IT业务的开发人员，大家使用的语言是不一样的。业务人员使用的是自然语言（中文、英文等），而开发人员尤其是编码人员使用的是编码语言，称之为是一种半形式化语言，完全形式化语言就是数学语言。虽然是半形式化语言，但也是有确定性的，把这个变量控制起来，就是把相同环境运用上一定会出来相同的结果，是有这种确定性的。但是业务人员不能够这样去描述问题，所以不一定可以描述清楚许多细节。可能就需要使用DTD的方法或者是低代码的想法，这都是从特殊角度去看待怎么帮助业务人员，可能会想办法丢失一部分细节，但一定要form这些内容，否则就会控制不住。即使做到这一点，但还是存在一定的鸿沟，它和devops两拨人还是不一样，这两拨人的语言还是一样的，可能一部分是编程语言，另一部分是脚本语言，但本质上还是半形式化的，还是可以达到一定共识的。前面的共识并不是说不能，而是有难度。我们现在能够做的就是借鉴，借鉴devops成功的经验会有一定的工具来承载一些被固化被沉淀下来的一些最佳实践方法，将它固化到流水线上。流水线可能更容易在一个企业中更快落地。很多企业表明已经在做devops，但是实际上可能只搭建了一个工具链，真正要去实现devops，发挥出devops的能力要考虑更高的层面，在实践、过程的层面甚至于在文化的层面去解决。但如果我们考虑前面biz和devops之间鸿沟，工具肯定是不足够的，因为工具在两边的描述力度、严格程度不同。但是如果我们从文化上改变他们的一些工作方式，这肯定不是短期内可以做到的。现在我们更能够接受的一种方式就是培养这种符合型人才。就像开发和测试人员如何进行妥协呢？即开发人员也要懂测试，提高他的能力。现在到了devops，开发人员也需要懂运维，到了bizdevops，还需要懂安全。其中让biz人员懂开发难度会更大，所以现在过渡期的一个方式就是培养符合性人才。符合性相对于学生是在做加法，而减法是一些标准的模型、工具平台，（以前是手动的，现在变成自动的），因为还需要考虑做减法，对于学生一直做加法，原来只学一门语言java即可，现在不仅要学习java，还需要学习函数式编程，还要学习脚本化部署的脚本，还要学习部署的运维运营策略。符合性也带来一个痛苦即需要学习的知识很多。但是现在这个专业的学生，他们的层级是越来越往上的，例如在90年代开发一个程序是从头开始编写，但是现在学生会直接使用一些框架，所以层次已经变高。以上都说到可视化模块，实际上bizdevops也涉及到业务层下沉到平台上，技术层以服务的方式下沉到平台上，这两处东西可见并且可处合，这就是我们说的下沉，这样能够让业务人员腾出精力。业务人员往前走一步走到结构化的程度走到dev的程度一定要经过很多学习。业务虽然偏自然语言，有不确定性和描述方式，但是我们可以提供一些方式去半结构化。某种意义上devops运动的兴起也是行业中的一致性认可，我们要做这件事情要抱着乐观的态度。现在谈到细节，有很多困难，但是如果忽视这些困难，我们的机会点在哪里？展望如果我们突破它，未来会是一番什么景象？最大的机会点还是在于需求本身。需求越来越迫切，在构建一个数字化的社会，数字化的商业生态，这一点对于我们的bizdevops融合要求是非常大的，一定会有一部分业务人员朝开发走的更远，而开发人员当devops解决了一系列工程问题后腾出手来也有自己的优势：形式化表达和结构化表达和抽象化表达、抽象分析的一些优势，一定可以给业务带来很多可能性。现在国家很感兴趣的话题是如何做创新，上一次万众创新，创新创业后，我们现在相对于处于一个创新创业的低谷期，如何再次激活也是一个新契机。创新也是一个高质量发展，高质量发展也需要工具支撑。作为研发人员或者业务人员，我们希望不会再被质疑业务导向还是产品导向。大家都为业务来扶服务，都在为同一目标努力，此时肯定会产生一些变化。例如我们的运维监控和运营监控将来可能成为一个技术，只是用不同的场景、不同的语句和方法模式。可以畅想到那时，我们的业务人员靠近研发和研发人员靠近业务都会变成一个非常自然的事情。例如现在测试和研发的界限越来越模糊，所以此时对于大家职业上会有一些变化，甚至可以认为在开发语言、技术的一些底层设施上都会产生一些新内容。例如会为了偏向业务角色产生一些特殊的编程语言与研发更好的进行描述，就像云原生时代发生的事情一样，以上是可以畅想的一些。云原生从某种意义上讲是开发和运维综合的产物。随着交叉越来越多，放到业务和科技也会产生像云原生这类东西。随着业务与技术将来的转换变得容易，从业务需求过渡到开发设计之间也有可能变得更加容易。无论使用哪种方式例如DTD等，业务还是业务，无论使用什么方式进行分析，业务都不会发生变化，所以我们要考虑是否有更自然的方式进行过渡，例如业务人员比较习惯分析自己的业务方式稍微结构化变成一种自然语言进行过渡。类似之前讲到的流程模型与数字模型之间的结合。当业务人员将行为加数据理解，那么两边就可以清楚。当业务层用这种方式进行过渡，从业务到技术变得更加自然时，其实还有一些问题，一个人员的职业发展方向其实可以有比较大的空间进行选择，那么如果bizdevops方式和可视化做起来后，一个人就更容易了解一个企业的全貌或者了解一个业务的全貌。知道每个不同的角色在做什么，自己可以往哪个方向选择。包括我们现在的模型方式，将数字化的转型或者企业要做的战略架构、技术业务进行转变与每个人需要的业务能力进行结合，也是帮传统企业的hr以及每个人看清数字化转型中有哪些部分，哪些部分中都有什么样的技能，如果从这部分到另一个部分，技能要做什么调整。bizdevops往下发展，可能将其中一些业务处理的内容开发处理的内容都暴露出来，让大家可以在一个体系下看清技能之间的联系和技能之间的变迁，这样对于个人的成长也会更好。这与传统的培养人才方式之间会有一些变化和新的创新。最近一两年可以明显感受到一个趋势，在软件行业中对整个公司的技术要求、产品要求以及业务的选择以及对于业务敏感度的要求是越来越高的。这与大家感受到的例如现在普遍在做降本增效或者高质量发展都是有衔接的。实际上以软件团队来讲，要想往前走，必须建立产研数字化的整个链路，必须将每一个对于业务需求的传导、对业务资源的投资要更加精确化，并且对于整个产研的过程需要全链路来看，来优化效率。原来的粗放型管理堆积资本的模式已经不可取，这是一个外在需求，大家都感受到了压力。包括现在金融行业在面临的数字化转模也是有类似的背景，大家都要提升相关的效率，该背景下未来会越强烈。另一个可能会发生的改变是企业内部会有人员积极拥抱这种变化，愿意接受这些新的方法，用一种半结构化的语言描述这种需求，能够希望快速的传到开发，让自己这种创新快速上市。这一部分人会在企业中脱颖而出，会成为新型的符合型人才，关键也在于业务人员能否与技术人员真正紧密的衔接配合在一起。例如一个人在上海做社区团购，可以将一些互联网方法技术方法融入进去，数倍提升小区的团购效率，这是一个典型兼顾biz和devops的角色。这是一个非常小的例子但是在未来很有可能企业会有这部分人冒出，在企业中得到很好的发展。该课程跨专业跨领域需要符合性人才，但是我们能够看到现在devops发展，畅想未来bizdevops，devops现在让我们看到例如云原生产品和系统越来越趋中心化，以微服务为主它的数字化从2022年开始90%的新的应用都会使用微服务，即趋中心化肯定是一个大的趋势，如果不做趋中心化，那么就没有办法进行devops。但是在这种情况下，我们做趋中心化时会围绕每一个业务或者服务来组织资源，有这种小的而自制的但是能够拉通的全功能的团队才能够好好发挥微服务的充分效能。再推论到bizdevops，这个链路我们还需要再进一步拉伸到业务层，让业务人员与开发运维人员能够紧密的工作。但是这样一个需求不能在短期内很快满足。现在畅想的是bizdevops，那么下一步能够做到了可能会有业务之外的组织上的一些其他的方式可能会成为最大的瓶颈。如果我们做到了bizdevops，那么原有的预算就可能需要改掉，或者说决策的过程战略都需要做相应的调整。但是如果我们认可这样假设，现在在做数字化，未来都会是软件的企业，都会开展业务和其他的部门对接。无论我们现在做不做，这个趋势都会发生，未来企业都要根据bizdevops进行企业转型，其他部门也要进行这样一个变革，这个结果其实就是一个逆康威定律，可以不做，可以抵制，但是其他企业做后就会有竞争。未来微服务的团队就是业务天然和bizdevops一体化的，整个公司的组织结构也变成了一个微服务架构。我们相信它能够真正意义上产生一些不一样的变化，也相信这一次的变革有与上一次devops变革的契机能够影响我们的产业甚至影响整个数字化时代。只有我们形成生态的时候这件事情才能发生。
-
发表了文章 2022-11-24
开源大数据 OLAP 引擎最佳实践 | 学习笔记（二）
开发者学堂课程【大数据知识图谱系列—如何选择合适的OLAP引擎进行数据湖分析：开源大数据 OLAP 引擎最佳实践】学习笔记（二），与课程紧密连接，让用户快速学习知识。课程地址：https://developer.aliyun.com/learning/course/1064/detail/15370开源大数据 OLAP 引擎的最佳实践内容介绍：一、开源产品—百花齐放二、技术分类三、开源大数据/数仓解决方案四、 ClickHouse 介绍五、 StarRocks 介绍六、 Trino/PrestoDB 介绍七、客户案例主要是介绍几种引擎， StarRocks 、 ClockHouse 、 Presto。主要是一些最佳实践，还有一些偏技术的东西。五、 StarRocks 介绍现在重点介绍一下 StarRocks ，因为 StarRocks 的熟悉程度可能不及 CK 或者是远不及 CK 。但是可能听说过 Doris ，而 StarRocks 实际上原名叫做 Doris DB ，他相当于是一个加强版的也就是一个 Doris+ ,也就是说 Doris 所有的功能 StarRocks 都是有的，但是 StarRocks 有的这种加速的功能 Doris 目前是没有的。1. StarRocks 价值这个也是一个开源项目，就是在 get help 里直接搜 StarRocks 就可以看到。这里主要强调几个点。第一点就是说他这个速度，这里面速度大多数可以认为是单表速度，这个单表速度实际上是可以媲美 CK 的，然后他这个多表 Join 就非常的强了，因为这个多表 Join 对于 CK 来说，他不是一个性能问题而是一个能力问题，也就是说 CK 很有可能是查不出来，而不是说查得慢。然后 StarRocks 在这里边是一个比较重点的，这个跟他的 FE 和 BE 的这种架构是有很大的关系的，还有他这种分布式的执行引擎是有很大关系的。第二个就是他的实时性，正常写这个速度能够达到100兆每秒，因为他这个是个事务写入，如果对比 CK 的话实际上是比 CK 慢的，就是说 CK 是一个非事务写入，也就是说这个 StarRocks 可以天生的支持这种 exactly once 的这种特性，因为只有全部写成功了才算写成功，就不会有这种部分可见的方式，所以他整个的100兆每秒的速度在同样的机器性能下，其实 CK 最多可以达到200兆每秒，实际上他这个写入速度还是跟 CK 有一定差距的，但是100兆每秒在大多数的这种实时数仓的业务是足够用了。第三个就是能赋能更多的人员，这个是什么意思呢？就是说 CK 是很吃资源的也就是说很有可能一个 C 口能够用到机器的一半的资源，然后他对资源隔离做的也不是那么的好，而 StarRocks 会在重点的方向去做资源隔离，这个资源隔离也就是说在一些小的 batch 的这种 C 的查询或者小的这种C口或者说是 MV 的查询上，实际上 QPS 是非常高的可以高到几千甚至上万对，在这种高 QPS 的方式下，这个 TP 99也是能做到一秒之内的。最后一个就是灵活的构建，但是强调一点就是这个 QPS 高的话，是达不到 serving 那种能力的稳定性，这个可能会介绍一下 hollow 的 sreving 方式，也就是说实际上他跟 HPS 或者说跟 hollow 的这种纯的 serving ，纯的用这种行存的方式，因为 StarRocks 里面是没有行存的，他还是个列存，接下来会细节讲一下，就是他还是一个列存的方式，所以说他没有这种稳定的 serving 的能力，如果是对接在线系统的话，如果要是不稳定的话，实际上肯定是不可接受的，因为可能一个查询不稳定了线上业务就出问题了。所以说 StarRocks 可以比较慎重的去用到那种场景下，但是他是更多的人员或者说是对这种广告主，广告主因为他人员虽然说很多，但是他能忍耐的时间比这个在线系统肯定还长些。然后这个灵活的构建，实际上 StarRocks 主要是强调了一个统和一个急速，对灵活的构建实际上就是一个统一的这种想法。2.重构企业数据基础设施这个就是一个 StarRocks 连接的几个源和几个 think 。第一个就是通过这个 CDC 或者说通过这个 ETL 的方式去灌到这个 StarRocks 里面；然后还可以去直接的和这些老的 kafka 或者是这种 TP 的数据库或者这种 log 的话，直接可以进行灌入；然后 External table 目前支持这种 hive 、es、 MySQL ，当然这里边还支持 hudi 和 Iceberg ，这个没有在PPT上是因为他在2.2的时候才会推出，这个部分是阿里云跟社区一起合作的比较重点去做的一个方向，会在 StarRocks 的2.1版本去做一个 experimental 的特性，2.2版本会做一个生产性的特性。3.架构—新一代弹性 MPP 架构这个是 StarRocks 的一个架构，这个架构就是有一个 FE 和 BE ，而这个 FE 有几个模块。第一个模块就是 catter log 的一个模块，就是他会存这个原数据，然后他还有一个 planner ,相当于所有的 MySQL 的第一站全部打到 FE 里，然后 FE 进行 SQL 的整个的解析，到最后的这个分布式的物理的 plan 的生成，然后都搞完之后真正的做整个的这个计算，是要在 BE 里去做计算的。他整个的这个架构是非常简单的，就是说在 FE 目前是一个稍微老一些的，因为这个其实是从 Doris 演化过来的,所以这是一个当时 Doris 有的时候还没有这个 raft 的这种玩法,但是现在社区 StarRocks 要慢慢的把 FE 改成这种基于 raft 的这种结构，它是目前现在是基于 Borken DB的，但是可以认为跟 raft 也差不太多，他是几台高可用的 FE 再加上这种 BE 。 BE 实际上做的就是这种 Execution Engine 还有这种存储引擎 storage engine 基本他就是这两个大的模块。实际上整个链路就是 MySQL 第一条打到查询的时候打到 FE ，FE 再把这个 SQL 文本翻译成这个分布式的执行计划，分布式的执行计划的数据都是按这种 buget 的方式去存到 BE 里。这一个这张表或者说查的这些 SQL 都命中了哪些 tablet ，会把这个相应的 SQL 的执行引擎给他搞到这个 BE 上，然后 BE 算完之后再回给 FE ，大概整个就是这么一个数据流。4.极速引擎—全面向量化这里就是 StarRocks 最强的就是两个，第一个就是这个向量化，第二个就是这个 CBO 。实际上向量化也不需要过多的解释了，其实这个图就已经解释比较清楚了。一个指令就可以把整个的这一列这几行全部都做完，然后这样的话实际上他会有更好的这种 cpu cache ，然后会有更少的这种虚函数的调用，实际上这几个是向量化的一个比较基础的一些东西都用上了。他整个的效果是显而易见的，因为只要是搞起来这个向量化和这个非向量化去比较，实际上这就属于快的能快到一个数量级，慢的也应该有五六倍的这种提升。所以说这块是一个 StarRocks 区别于 Doris 的一个比较重要或者说是非常重要的一个特点，就是他是全面的向量化，他把所有的算子全部的向量化掉了。5.极速引擎—全新 CBO然后这个 CBO 实际上也是一个比较重要的， CBO 有两个比较。第一个是和 CK 去比，而第二是和 Doris 去比。如果跟 CK 去比，其实是比不到一个层面上，因为 CK 目前一是没有 CBO ，二是他连一个比较通用的一个planner 目前也是没有的；相当于就是说从这个 SQL 一步步最后走到分布式的物理计划然后在 BE 里面执行，实际上经过这几步，第一步就是相当于是这个词法和语法的分析，分析之后去做 SQL 的 rewriter 也就是常常说的 RBO 也就是基于规则的这种优化实际上是在 rewriter 那一步的，然后 logical 这个plan 实际上去看一下已经统计的一些信息，这些信息就是比较常见的一些信息包括一些直方图这种这些不同的列，或者说是跟不同的这个 scheme 相关的一些 static ，然后基于这些 statics 去做整个的这个plan，然后这个plan比如说在这做 Join的时候会做的非常的好。就比如说 ABC 这三个做 Join ，究竟是 A join B 还是 B Join C ，到底哪个 Join 最好。实际上整个奥卡论文都已经说的是比较明确了，然后整个的这个也是经典的数据库里边的一些理论，这些都已经做进去了。6.极速引擎—多分布式 Join然后这个就是分布式的 Join ，这个分布式的 Join 目前就是 CK 比较缺乏的一个功能。这个左边的图和右边的图，如果了解 spark 或者了解 presto 的话，其实都应该知道这都是有的，就是说这个其实就是做 Shuffle ，就是把不同的 Key 给 Shuffle 到同一个 bucket 里边，然后再去做 Join ，然后右边实际上是一个更加高效的一种 Join 方式也就是提前的去做好了这个 bucket 的分类，也就是说同一个 Key，两张表相同的 Key ，全部落到同一个 bucket 的范围，然后这个 bucket 的之间肯定是没有 over lap ，所以可以放心的做这个Colocate joy ，在这个 spark 里面也叫 bucket join 。7.全场景—丰富的数据模型然后这个全场景实际上他提供了四种模型，第三种模型是 StarRocks 2.0新出的 primary key 的模型。他首先支持第一个明细模型，明器模型实际上是区别于刚才说的那种聚合模型，就比如说纸质聚合模型的，包括 dryed ，包括 Kevin 就是包括这些模型实际上有一点不好的，就是没有明细模型就没有原始数据，并不知道这个原始数据怎么去搞的这个聚合模型，万一要去查这个明细模型如果没有，实际上整个数据是一个丢掉的状态，只有去从这个 Hadoop 里，如果有的话可以去 Hadoop 里面去捞，那整个数据看起来就比较碎了，就不太容易去挖掘出来了。然后聚合模型就是相当于是有两种，一种就是直接导成聚合模型，比如说刚才直接用 spark 或者 flink 直接导成聚合模型，还有一种是基于明细模型来出了这个聚合模型，比如说用这种 materialized view 的这种方式，通过只灌这个明细模型，然后去提前写一些聚合的这种方式，做一些 MV ，这样实际上在这种查询毫秒级别的，就比如说几十毫秒或者是200毫秒以内可能用聚合模型用的比较多，这种适用的就是完全的知道每天需要的这个汇总和分类，是完完全全的都知道的，而且也不会有什么太多的改动的，会用这种聚合模型。然后这个主建模型实际上就刚才说的，这个主键模型和更新模型，可以认为主见模型是更新模型的增强，如果主键模型比较稳定的话，其实更新模型就没有什么太多的用处。主键模型实际上针对的就是 CDC 的这种场景，或者说是这种订单变化的这种场景，会以非常快速，因为刚才说就是 CK 的方式，CK做这种变化，做这种 Upsert 的这种场景实际上是有缺陷的，因为 Upsert 场景，他是通过后台的这个 conpation 之后，才会把整个 delete ，还有 Upsert 给他更新掉。但是这个主建模型实际上就是有这个唯一的主键，那么这个主键一旦要是发生，比如说订单的 ID 号其实是在内存里边的，然后内存里边有一个 road path 相当于有一个指向每一行的一个 position ，然后这个时候一旦发生了变化就会 delete 掉原来的这条记录，然后会 Insert 一条新的这个记录，所以这个感官上体感上来看就是非常快的可以做变更，基本上做完之后直接就能实时的看到了。8.全场景—高并发查询这个是高并发查询也就是刚才说的，可以看一下最后的一点，就是说这个高并发查询，实际上是针对其他的这种 OLAP 引擎，如果要是和这种行存的 OLTP 或者和这个 hollow 来比高并发的查询，实际上是没有那个稳定的，因为 TP 这种行存的话，肯定是最稳定的一个 serving 的这种状态。那这个相当于可以认为是逐渐的缩小范围，做一个 table ，然后再做一个 partition ，而 partition 里又分成不同的这种 bucket ，不同的 bucket 中每个 bucket 都有这些 bloom filter 还有一些 blocked index 类似于这些可以做一些 data skipping 。所以说这个 data skipping 做的一旦非常快或者这个主键的索引叫 short key 做得非常的快的话，实际上是能够很快的去做这种高并发的这种查询。9.全场景— LakeHouse全场景还有一个就是 LakeHouse ,也就是刚才说的会在 StarRocks 的2.1和2.2的版本会把 Hudi 和 Iceberg 全部都支持了，因为 hive 目前已经是支持了。可以看一下这个测试的结果，实际上可以和大多的跟这个 presto 去相比，因为他对这个外表查询实际上跟这个 presto 的这个结构上是没有什么太大区别的，但是他对向量化引擎的这个优势是体现的比较明显的，也就是说在这个 presto 和 StarRocks 来比的话，实际上可以认为完全的就是计算层的这些优化进行了一些加速，毕竟这个 presto 还是由 Java 来写的。当然这个 presto 目前就是 Facebook 也在推这个 presto 的 C++ 的这个方案。可能后续也要开源，听说可能是也要开源，这个可以到时候再对比一下。10.易运维—弹性伸缩，在线扩容然后这个运维就是比较简单的，实际上他相当于可以跟几个维度比。第一个就是跟这个 Hadoop 整个的一个生态来比，如果这个业务非常适合用这个 StarRocks 来替代的话，实际上他这个运维比 Hadoop 要简单的多。然后再一个就是跟 CK 来比，这个在运维上实际上也是有很大的提升的，因为 CK 毕竟没有一个类似于 FE server 的这种方式,然后这个相当于就是每添加一个节点就会自动的做这种 balance 。就比如说添加一个四节点，然后原来的比较满的这个节点也就是那三个小的虚线框就已经过来了，对这个不需要改，只需要在 MySQL 里去增加一台 backend 就可以了，他会自己做这个平衡。六、 Trino/PrestoDB 介绍1. EMR 数据湖架构最后再介绍一下 Trino 和 PrestoDB ，而 Trino/PrestoDB就是说这是最经典的一个数据湖的架构，数据湖架构就是说最底层是 OSS ；然后其上就是这个 Hadoop 的这种 API ，相当于这边是 Jingdo FS 来去做这个 Hadoop 的 API ，然后还有包括这种 cash ；然后再上面一层就是这个数据湖的几种格式；然后再上一层就是这个引擎还包括他的调度，而这边 channel 的这个引擎其实跟就是刚才介绍的 Prseto SQL ，可以认为跟 PrestoDB 差不多。然后这个 Presto 直接去通过数据湖的引擎去查询这个数据湖，这个应该是一个比较经典的，比较老生常谈的一个方案。2. EMR Trino然后在这个 EMR Trino 实际上主要关注两点。第一点就是说提供了K8S 的形态，这个在不同的客户里边也已经逐渐的用起来了，然后整个 EMR 产品里也有这个 K8S 的形态，目前提供的是 spark on K8S 还有 Trino on k8S 。然后第二个强调的一点就是整体对这个数据湖的这个加速是非常的好的；因为这个数据湖，比如说 delta ，比如说 Hudi 和 Iceberg ，很多的这个 PMC 都在阿里团队下边，然后实际上有一些非常好的一些特性，然后这边 Trino 都是配了在这个开源的 Trino 上实际上是没适配的或者说优化的不是那么好。所以说这是比较重要强的调两点，一个就是从成本上看，就是可以做在这个 K8S 里边，然后还有从这个数据湖上可以看到做的优化比较多。七、客户案例然后最后讲几个客户案例，就是这几个客户案例其实都是最开始在抽象那几个里从实际的客户案例里面去获得的，然后这个看起来也就不陌生了。1.某在线教育客户这是一个在线教育的客户可以关注一下他这个业务背景，就是这个业务背景最开始就是几十一条的这个数据，其实这个业务量在这之前应该算是不大不小，他现在面临的就是这个订单变更，订单变更就是比如说上课什么的这些确实是变更，还是说有一些预售或者有一些补售，或者说这个订单状态会时刻的改变，然后他们还有这种特征人群的这种圈选，就是说做一些应该是每一家数据公司应该都有的这个痛点，然后还有一些机器学习的这种训练。然后最开始的方案实际上是处理的不及时是一方面，还有就是说这 hive 架构有的时候他就是没法做，就是这个小时级的这个任务他做不了，就是小时级的任务，实际上整个看起来这个样就非常的繁忙了，因为每一次都要做一个上一个小时的所有数据的一个 in search of right 实际上整个集群看起来比较繁忙；然后还有一个痛点就是刚才搞不定这个 Upsert 的这种场景，他只能用这个 in search of right 相当于比如说第二天变更了第一天的数据，那只能说是把这个链重新再做一遍，当然也有一些拉链表什么的这些方式，但是这个资源耗费还是比较大的，就是典型的不是这种 Upsert 的场景，所以做完这种 Upsert 的场景有几个收益。第一个收益，就是说这个 Upsert 的场景就支持了；第二个就是说 presto 去查这个明细数据，而这个直接用 Hudi 就可以搞定了。然后他是用的 CK ，他主要是做两个。第一个就是 Hadoop 查询，所有的运营人员都能通过 CK 去做这个 OLAP 的 Hadoop ；然后第二个就是说他会支持一些 bi 报表，而报表有的是通过 CK 来的。2.某社交领域客户这个是一个社交领域的客户，社交领域的客户是用了两个数据仓库也就是利用两个两款产品。第一款产品实际上他做的是一个宽表，他认为或者说当时在他选型的时候， StarRocks 这个宽表做的速度可能跟 CK 比还是稍微差一点，所以他现在用的就是 CK 也就是做的是纯的宽表。然后这个 flink 已经事先的去聚合好数据和加工好这个宽表，然后直接 load 到这个宽表里，他给出反馈就是说最差也就五秒，就是PPT 上的一到五秒，实际上是一个比较保守的，他有很快的时候可能就是几百毫秒，然后比较快的基本就是五秒，很难说是有五秒之上的这种查询，因为他这个 OLAP 实际上是事先这个 adhoc 是没有定义的是随想随查。然后第二部分，就是做的这个 StarRocks ，这块就是他基本上来说做的都是聚合表，然后这个聚合表实际上是用的 StarRocks ，然后他主要是两方面的一个需求，一个是业务的检查，这个业务检查基本上他搞的就是那个广告主，就是给的广告主那个检查，并不是像刚才说的在线系统的这种查询，因为在线系统查询的话，目前来看还是 hollow 或者说 hbase 类似于这种的 service 系统才能够做的非常稳定。还有一个就是关联的 Hadoop 查询，然后 Hadoop 查询他给的实际数据不超于十秒，当然他这个不超于十秒，实际上是有 Join 在里边的，因为有了 Join 的话，对这个 Join 没有做特别多的优化，实际上有的时候就是比较慢，这是他们给出来一个数字。3.某电商领域客户然后还有一个就是电商领域，这个就是一个非常简单的一个玩法，相当于就是手里边有一个 MySQL ，当然这个可以看一下这个数据量其实不是非常大，就是所有的 MySQL 直接连 kafka 都不要了，所有的 MySQL 直接通过 flink CDC 直接给他搞到 StarRocks 里，然后 StarRocks 相当于跟 TP 的完全镜像的一个数据库，可以这么认为。相当于所有的表都是同步的，最开始用的 migration 的 tool 直接把所有 MySQL 的也就是想要的这些表，全部都导在这个 StarRocks 里，然后直接用这个 flink CDC 直接搞，因为这种搞法实际上是一种返璞归真的一个搞法，所以说这个就相当于这里边该有的表都有了，然后该怎么查就怎么查，所以他用的基本上都是这种 OLAP 的这种查询，然后对接这个业务系统的 serving 用的也是这个广告主的这种 serving 实际上他也不是用的这种在线系统 serving 。这个优点就非常清晰了，就是说他这个链路就非常简化了，他需要运维的操作不多，基本上就是增加一些节点，就是如果要是节点少了就增加一些节点，然后看看监控或者报警什么的，其实他就比较轻松，就是面对比如如果是用 MySQL 来去做一套整个 Hadoop 体系，实际上他需要操心的事儿还是挺多的。
-
发表了文章 2022-11-24
开源大数据 OLAP 引擎最佳实践 | 学习笔记（一）
开发者学堂课程【大数据知识图谱系列—如何选择合适的OLAP引擎进行数据湖分析：开源大数据 OLAP 引擎最佳实践】学习笔记（一），与课程紧密连接，让用户快速学习知识。课程地址：https://developer.aliyun.com/learning/course/1064/detail/15370开源大数据 OLAP 引擎的最佳实践 内容介绍：一、开源产品—百花齐放二、技术分类三、开源大数据/数仓解决方案四、 ClickHouse 介绍五、 StarRocks 介绍六、 Trino/PrestoDB 介绍七、客户案例主要是介绍几种引擎， StarRocks 、 ClockHouse 、 Presto。主要是一些最佳实践，还有一些偏技术的东西。 一、开源产品—百花齐放现在先说一下 OLAP 的中束，这个中束可以看一下这个表格；和一些客户做交流的时候总是问起来这些问题，就是说现在这个花花绿绿的这些所有的这个 OLAP 的引擎，有的是 OLAP 相关的，还有一些是类似于原来的这种批处理相关的这些引擎；然后他们到底怎么选、怎么组合，这其实是一个比较好的问题。这个问题实际上对这个数据处理来说，因为数据处理有很多种路径可以达到同一种目的；每一种这个路径，比如说从最开始的 OLTP 数据库到这种大数据的发展，最后到这种 OLAP 的发展，还有中间夹杂着各种并行的，然后这里边还有很多 trade off ，还有解决不同问题的这种痛点，所以说今天主要是来梳理一下。这些都是什么样的这种含义，怎么样的去组合这些才能发挥出这种业务价值二、技术分类然后在这里面做了归类的一个总结，主要第一种也就是 ROLAP ，这种 ROLAP 可以认为是那种相对来说存储一体的，是一种类似于数据仓库，比如 snowflake 或者说是闭园的 snowflake ，然后有这种hollow，还可能的是这种比如说 max compute，也可以归结到这里边，就是存算一体的数据仓库。在开源领域比较重要的就提炼出来三个，其实还有包括这种green plum什么的都没往上写，现在用的比较多的，脱颖而出的基本就是 StarRocks (DorisDB) 、 ClickHouse 、 Apache Doris 。然后这里边可以说一下 StarRocks 的一个进展相当于是原来这个 DorisDB 出来的，然后他现在目前的这个发展的这个趋势在 gethap 上的这种 trend 实际上是一个非常好的一个趋势，他目前应该是完全替代了这个 Apache Doris 这个项目，相当于他可以被认为这个 StarRocks 是一个 Doris+ 或者是 Doris plus 这种感觉，他覆盖了 Doris 的功能，然后在这种单表、这种向量化、在这种 CBO 什么的做的是更加优秀，然后也用了很多最前沿的一些技术。第二种就归为一类了，比如说这种预处理的、类似于预处理，类似于这种线上能够提供这种 certain 的这种服务，比如说这种 Druid、 Kylin 或者是 HBase ，当然这三个的技术实现是很不一样的，但是归到一类相当于在业务里边可以认为他们有一部分是重叠的。比如说 Druid ，做的都是非明细表，然后都是一些聚合表类的查询，比如说像 ansbook ,主要是解决这种不同的数据源，比如说 CSV 格式、包括这种 part 格式，把他们统一成同一个这种 table format 模式，这个就是一个大体的分类。三、开源大数据/数仓解决方案然后下面会介绍一下开源大数据的一些数仓方案，这个数仓方案主要就相当于是一种组合的方案，就是知道了这些技术，然后这些技术怎么组成一种比较合理的带有业务价值的这种玩法。主要是分为几个部分，第一个部分就是看一下 EMR 的整体架构；然后从 Lambada 的架构开始讲，讲到最后比如说一些推出的这种实时数仓方案，大概从开源的领域到底应该怎么去建设。1. EMR 整体架构这个就是 EMR 的一个整体的架构，这个整体的架构和今天 OLAP 关系不是非常的大。构建一个大数据平台，其实无非就是以下这几种。第一个就是 ECS 层，然后 pass层基本就是业界比较通用的这种样儿；目前这个 K8S 也逐渐的走进了大数据的这个领域，包括这种 flink on k8s 、 spark on k8S 还有 press on k8S 。越来越多的这种引擎都已经在 K8S 上跑了，也有一些在生产实践中用的比较好的，包括近期阿里云 EMR 开源的这个remote shuffle service 实际上也是在支持这种 K8S 形态的方式的一个必须的一个组件，在 Spark on K8S 的一个必须的组件，还包括 flink 也开源了 remote shuffle service，他是支持这个 flink 批处理的，是在 K8S 上的一个增强的软件。然后下一层就是存储层，存储层的话， EMR 比较明星的一个产品就是 jingdoFS 提供了一种 Hadoop 接口的,以 OSS为基底的这种方式，也就是说在计算引擎，包括 spark 、 flink 、 presto等，他们完全可以不感知后边是 OSS ，直接还是用 Hadoop 的这种接口去直接使用这个 OSS ，这个在成本上和扩展性上，实际上是有一个比较大的提升的。然后下一层就是数据库格式，数据库格式主要是解决了几种痛点，比如说 absurd ，比如说这种统一的元数据管理。然后上一层中的绿色部分是今天比较重点的部分。然后其他，就是包括 spark ，包括最老的这种 map reduce ，还有一些机器学习相关的东西。然后再上一层就是阿里的一个产品，这个产品相当于就是 bi 的产品，包括一些 datawords 的产品，还包括一些 EMR 提供的 tools 。最右边的就是一些权限管理的一些监控，包括一些资源的打标、日志等一些服务。这个就是整体 EMR 的构成，后续会主要讲绿色这些部分。2.离线数仓体系— Lambada 架构现在来看一下目前状态用的最多的一个离线数仓体系，就是这个 Lambada 架构。 Lambada 架构其实就是分两条链，第一个就是实时这条链，他实际上从数据源开始，数据源就是有这种 CDC 的数据源也就是 LTP 的这种数据源，还有就是类似于这种流量的数据源，一般都是 log 或者是包括一些行为的数据分析，然后他们都到这种圆的 kafka ，然后通过上边的一条就是 flink 去做一次加工或者说做几次加工；最后给他灌到几种形态里边，有的时候直接灌是这种 redis ，还有 kafka 结构的这种 Hbase ，然后包括还要给他灌到这种 sik 里面，灌到这种 StarRocks 里边。主要提供的是几种服务；第一个就是，如果这个 redis 或者是 Hbase 希望的是业务在线系统能够直接的对他们提供这种 service 的能力，也就是说在线系统可以直接调用这种 API 了，因为他检查的这种效率是相当高的；第二个，就是说要给他导到这种 OLAP 系统里边，把这些所有聚合的数据或者说是这种半聚合的数据都导在这种 OLAP 的系统里面，然后运营人员可以快速的去用他自己的思维即事先没有定义好的，可以去 adhoc 一些想要了解的运营数据，因为每天这种数据科学家也好，还有就是运营人员也好，他每天的想法可能是不一样的，他突然发现有一些新的这种数据的这种感知，可以通过灵活的这种 OLAP 不间断式的去完成思路。第二条链就是离线链，离线这条链实际上他有几个想法。第一个想法就叫做 log retention ，这个就相当于 kafka ，认为他不是一个最终的日志保留的一个介质，怎么看他都是一个临时的介质，比如说会配这个 log retention 可能是七天或者说是三天，但是都不认为 kafka 是一个长久保存数据的，所以一定要有一个这种长久保存数据的这个口，所以一般用的都是这种 hive ，然后把所有的这个 kafka 全部都 load 到这个hive里边，然后在这个 hive 里边去做这种 insert all right ，其实提到hive，如果没有增量数据库格式，都是用 insert all right ，就是把 ODS 所有这个表都 load 完了，然后用这种 packet 的方式去做上一层的表，包括这种 DWD 的detail 的表，然后在这种 detail 的表上面再去做一些数据集市或者说数据产品的一些表。这些表其实有两个出处，一个出处就是事先定义好的这种 bi 接口，直接 T+1 直接就跑到最右边的这种报表的形式;还有一种是把他里边的比较热的数据给他 load 到一些 OLAP 的这个产品里边，包括 StarRocks 、 ClockHouse ，主要这个也是提供给这个运维人员的一些输入；第二个想法，这个底线收藏比较重要的一点就是实时，很有可能实时做这个数据订正实际上是不理想的，通过这种 T+1 的数据，比如说同一个数据的口径不是特别的一致，然后通过离线的这个 T+1 的这个口径来去订正这个实时的这个口径，这是比较重要的即 hive 比较重要的两点。当然这个就面临着一些问题，这个问题可能最重要的问题，第一个就是数据里面像 one single truth 就是相当于他的数据来源是同一个或者数据口径是同一个。如果这个数仓做的比较久，应该知道离线的和实时的这个口径实际上很多的时候是无差的，一般来说在七加一的时候都会去更正一下，也就是说可以认为是实时一般得出的是一个近似的值而离线得到的是一个准确的值。3.实时数据湖解决方案然后基于上面的一些痛点也就是业界发展出来这种数据湖的一些方案。数据湖的方案一般来说，都选这个 ICEBERG 、 hudi 还有 delta lake 。 Delta lake 一般就是 spark 战也就是说如果所有的数据引擎全给予 spark 来说，这样的话直接基本就是搞 delta lake ，因为delta lake 毕竟是 data bricks 开源的，所以说他对 spark 支持是最好的。然后比较通用的就是这种 hudi、 ICEBEGE 这种链路是什么？就是说解决了上一个链路的一个离线这条链路的问题，那直接就是全部都通过 flink 去走这条路径。这条路径实际上解决了两个大问题。第一个大问题还是说这个数据，因为这种的数据 ICEBEGE 或者 hudi 基本都是保存在这种对象存储上即 OSS 上或者 HDFS 上；解决了第一个问题就是 log 不会丢，最后肯定都是在这种永久的存储上。第二个解决的是他的一个时间级别的一个问题，这个比如说 hive的话，应该都用的是 insert all right ,做一次这个 hive 的表的话，实际上要求的资源是一个全量的数据;但是做这个 hudi 或者 ICEBEGE 的话，要的是一个增量的数据，增量的数据肯定是要比全量的数据要小的，所以说在做这种更小级别更细力度的这种数仓的话，实际上是有这种方式的，因为 hive 的话一般来说做的都是天级别的，还有的在实践中有这种做半天级的、有这种做小时级的或者几小时级别的，但是再做细粒度的实际上就已经搞不定了，因为每个都要调度实际上整个会特别的繁重，整个这个集群跑起来，如果要做这种分钟级别的或者半小时级别的这种数仓，如果用 hive 来做，实际上集群会非常的繁忙，但如果要是用这种增量的方式去做整体上整个数据链路可以做到分钟级别的，其实再小的级别可能也用的不好了。一般来说，做小时级别或者分钟级别，可以尝试用 ICEBERG 或 hudi 去做。下面画一个presto，就是说 presto 是可以连接整个 ICEBERG 或 hudi ，只要落到这里的增量仓里就可以直接用这种presto去做这种查询。然后最终的归宿也就是所有这个数据，要么就是直接躺在这种 ICEBERG 和 hudi 里；然后还有一部分比较热的数据即非常关心的数据，要么就是给他放到这种 hbase 的 service的系统，要么就给他放到这种 OLAP 系统，然后能更加速度。后续会有一个时间范围，比如这个 presto 去查这种 ICEBERG 、hudi 的这种表的话，经过一些优化和比较多的原数据的元数据的提取，还有这种 data skipping 的这种操作，实际上能够查到几十秒，就是十秒至几十秒或者更快的可能四五秒；但是在 OLAP 里边实际上如果数据 load 到这里边，由于他是存算一体的，还有 SSD 这种加速，所以说大概就是毫秒级的也就是几百毫秒。4.实时数仓解决方案（1）方案一再往下演进就是这个实数仓的解决方案。这几种方案并不是互相的替代的关系，而是说这些方案更适合某些的场景，然后这种场景实际上其实是一个比较传统的或者说比较流行的一个实时数仓方案，就是实时数仓的每一层都是用这种 kafka 去做也就是用 flink 加 kafka 去做每一层的实时数仓，但是每一层的实时数仓刚才还是要解决一个问题即 log retention 的问题，怎么保留住这些 log 。那这些 log 可以给他加载到这种 StarRocks 里，也就是说 ODS 层做完之后，这个 kafka 实际上可以连一条链也就是 kafka 直接用 flink 或者 StarRocks 直接消费 kafka 就把 ODS 层都 load 到这个 StarRocks 里了。同时这个 DWD 层、 DWS 层，每层处理完之后全部都是增量的落到这种 StarRocks 里也就是说这个 StarRocks 可以完全的去把整个的各种层全部的给搞到一起，那这样实际上所有的层都在 StarRocks 里了。刚才说的这种无论是 bi ，还有这种 adhoc ，还有这种 API 的 serving ，还有最后的 OSS ，实际上就是 StarRocks 可以有两种方式。一种方式就是冷热的方式即 StarRocks 里面存的数据比较冷的或者比如说认为可能七天或者说一个月的数据给他导到冷备里边，导到 OSS 里边；还有一种就是如果 StarRocks 可以做这个外表的关联，能够直接读这个 OSS 里面的数据。这下面画了四个小框，而这四个框是怎么保证是没有问题的呢？第一个方框就是说速度快，也就是做了销量化做了这个新的这种 pipeline 这种执行引擎，做了这种全新的 CBO ；第二个方框的 Materialized View ，一般来说就是预处理也就是说订一些预处理好的这种C 口去实时的更新这个 Materialized View ；第三个方框的Resource Group ，实际上就是一种资源的管理，就相当于是资源之间互相不打架，各种租户之间互相不打架；第四个方框的 External Table ，就是刚才针对OSS 这部分说的。（2）方案二下一个解决方案实际上是一个可以想到的一个未来的一个解决方案，目前 StarRocks 正在往这个方向去做也就是 kafka 的数据直接给他灌到 ODS 里边，然后整个这个 StarRocks 自己去做一些 trigger，做一些 micro-batch 的这种任务调度器直接可以用 ODS 到这个 DW 和 DWS ，这几层全部都是用这个 StarRocks 来完成的。如果已经落入在这个数据仓库里边，实际上有的时候这个建模也未必是完完全全的按照这种 ODS 、 DW 、 DWS 类似于这些比较传统的方式去做，可以经过一些更多的简化也就是相当于用同一套数据仓库的这种引擎去做整个的这种数仓的这种方式。5.使用场景小结然后这里是做的一个小节，这个小节实际上整个趋势性也就是看到一些趋势性的东西。（1） Lambda 架构Lambda 架构一般来说是所有的大厂里边目前都没有去掉 Lambda 架构也就是虽然说 Lambda 架构痛点也都很清楚，但是在大厂里边只能说是越来越多的这个业务去往实时的方案去转化，实际上这个 Lambda 架构是从来没有被去掉过的。这个比如说有一个厂已经是10PB 级别的，希望以离线的这个底座去做这个数据中台，然后所有的数据全都给他存储到 OSS 和 HDFS 里边，有了这个基座之后会进行一些数据的加工，会把这个离线数据给他加工到这种 StarRocks 或者 CK 等类似于这种 OLAP 引擎里边。在这里边其实如果要做到 CK 里边，是需要做这个大宽表的，因为 CK 不适合这种 Join的级别的东西所以必须要做大宽表，做完大宽表。这个 StarRocks 和 CK 理论上来说，他在这个做 OLAP 查询里边，90%或者99%的这种命中率，基本上都是在500毫秒至两秒的，大概就是这么一个范围，可以灵活地去做这种 OLAP 。然后实时链路就是刚才说那种，实时链路如果是到这个 OLAP 引擎里边，大概查询起来也是500毫秒到两秒。这里面重点强调一下，就是如果 Join 做的比较多也就是说这个宽表做起来不及时，或者说这个宽表做起来有难度，或者说没想的那么明白、没想的那么清楚，肯定这个 C 口里面会有很多 Join ，那么这个Join 用的比较多的情况下 StarRocks 是一个很好的选择。同时 StarRocks 目前在这个单表的能力实际上现在应该是可以比拟 CK 。在某些场景下，比如说在 TPCH 这种标准的测试下边，实际上相差的已经很接近了。（2）实时数据湖方案然后实时数据湖的解决方案，就是刚才强调的，还是希望这个数据存到 OSS 或者 HDFS 里边。然后也希望统一这套代码，比如说这条代码全部用 flink 来做或者完全用 structured streaming 来做，希望完全的统一整个的代码。然后这个数据量，在经手过的业务，基本来说是10PB 以下的，但是他的扩展性不见得是10PB 以下，所以保守的写就是 PB 级别的，用这种方式实际上是没有太大问题的。然后业务有几个需求，比如说有 Upsert 需求，而 UPS的需求理论来说应该是非常多的，比如说这个订单需要随时改他的状态，最开始这个订单是一个未付款的状态，而这个付款有的时候类似于网约车什么的有很大的付款延迟性，可能一天之后才付款，然后一天之后要把整个这个订单重刷一遍，哪些订单是延迟付款的；还有第二种就是希望做这种分钟级或者小时级的数仓，这个刚才强调了，他会比较大量的节省这种调度的资源，节省计算的资源。其实要是直接从水位线上看，就是这个样就不是那么繁忙了可以这么认为，或者说整个物理资源用的 load 也不是那么高了。然后在这里边也是有，就是要把这个最热的数据给他导到这个 StarRocks ，然后大概来说是一个一秒两秒的这种试验。如果要是直接去用 Presto 去查这个 Hudi/Iceberg/Delta ，可能试验大概是一个五秒至30秒，这些结论实际上都是一个采样的数据，可以认为这是一个 range 。（3）实时数仓方案最后这个实时数仓方案这个方案实际上就是他已经突破了原来说的这套 hadoop 系统了，他跟前两套就已经是完全不相关了，他其实就是突破了 Hadoop 系统。他这个每天增量数据是10TB+ 这都是真实客户案例，希望以单软件或者单组件的方式去做这个底座，因为一套 Hadoop 系统，实际上需要装的组件是很多的。比如说相当于在数仓方案的，就是以这个 ClickHouse 或 StarRocks 去做这个基座，然后把冷的数据也就是第一站直接给打到这个 CK 和 StarRocks 里，如果要是有这种冷的数据才去给他做到 OSS 里边做一些冷背或者说做一些资源的一个成本的一个优化，这个特点就是运维很少，不会去做这个运维体系，比如说一个 MYSQL 客户端，或者因为 StarRocks 是完全兼容 MYSQL 的这个客户端，一个 MYSQL 的客户端，或者说一个 CK 的一个客户端直接就做了，这个运维起来比较简化的话，那么相当于就媲美全托管了，但是整个在 EMR 上的成本还是比全托管要便宜的。然后实时性也非常的强，因为相当于现在就是比如说 CK 的话，直接做的就是大宽表； StarRocks 也是做这个用 flink 做一些数据加工，只要导入之后，那么大概的查询基本上都是在秒级别或者是百毫秒级别，不会有特别大的这种偏差。还有就是后续要推存算分离的这种方案，这种存算分离的方案相当于会以这种 OSS 为底座，然后以 Cache 加速，这种 Cache 会用这种 JingdoFS 这种明星产品去做 Cache 加速，所以这样一旦推起来实际上认为就比如说一个合理的建议，十台 Hadoop 或者是20台 Hadoop 类似于这种的量，实际上可以尝试一下直接用这种第三套方案就可以一站式的做这件事而不是说在学校去维护一套十台或者是几台 Hadoop ，去做一个小的那种 Hadoop 集群的那种方式。四、 ClickHouse 介绍讲了这些之后，会简单的或者说大概的介绍一下这几个内核。1. ClickHouse 是什么那第一个就是 CK ，实际上做数据的大体上都听过也就是大体上都知道，在这里就再去复述一下。第一个他是一个列存的数据库；然后他是一个 MPP 的架构，其实这里边说的 MPP 实际上是一个广义的 MPP ，如果是带 shaforing 的这种 MPP 实际上 CK 是不具备的，他其实更可以看成就是最老的那种分级，叫 scatter gather 的架构，相当于他会把整个的 C口 分布到多台的 CK 上，然后多台的 CK 算完结果之后，最后再聚合到某一个节点，然后再 to 给这个用户，实际上他是这种 scatter gather了而不是那种大规模的 MPP 带 shaforing 的那种方式;然后他最大的特点就是快，实际上就是这个向量化的支持做的特别好，而且他对细节的把握比如说他做这个 aggregate 的时候，正常做 aggregate 可能想就搞一个 hash map 就可以了，但是他这个 hash map 可能有十种以上也就是说他会对不同的方式用不同的 hash map ，所以说整体上看就是一个细节优化的特别棒的一款引擎；然后他对 SQL 的支持也基本上是完善的，虽然说没有 StarRocks 这种 MSQL 的方式，ICSQL 支持的好，但是基本上来说也是一个完善的；但是他可能对这个实时更新做的或者说实时删除做的不是那么好，因为他毕竟还是类 LSM 这种 tree 的方式，他还是用合并的方式去做删除和更新，所以这块做的不是那么实时；然后现在这个社区也是在逐渐的开始意识到这一块，因为 Upsert 的这种功能，还是 OLAP 的一个必要的环节，所以社区也在往这边做对。如果使用过 CK 的话，可能会认为他的数据量是一个中等的数据量，比如说是百 GB 类似于这种级别的，基本上都是秒出。2. ClickHouse 为什么这么快主要他就是类似于 LSM Tree ，然后他整个的这个数据文件实际上就是把 table 每一个，因为写 CK 的话就不会去一条一条的写，一般都是攒一个 VP ，比如说攒一个十兆的或者说攒一个20万条的，比如说在 flink 或者在 spark 里边攒完，攒完之后一次性的打到 CK 里边， CK 就先把整个的这一个 block 也就是这一个 ablock ，相当于把各种的这个列给他拆开，然后把每一列都进行排序，排序完之后，每一个列形成一个并文件，可以看到一个 part 会形成一个文件夹，然后这个文件夹会有 .bin ,“.bin 就是有几个 column 就是有几个 .bin ”这里的细节就不展开了，因为还有一种不是几个 column 等于几个 .bin 的那种就是 compact 的方式，这个就不展开了。就比如有五个列，那就是五个 .bin ，然后还有相对应的 mark ，还有相对应的 PK 的 index ，而 pk index 和 other index 其实和 tree 里边的或者跟 bplus tree 里边的 index 实际上不是一个东西，那个 index 实际上是行存的一个索引直接能通过某个 key 就能找到对应的 roll ；但是这里边这个 index 实际上就是一个 data skipping 的一个方式，比如说他这个 other index 里面可以有这个 bloom filter 还有一些其他的这种 Data skipping 的 index 。也就是一个稀疏索引，而这个稀疏索引大概是去查整个范围或者说查某一个等号这种方式，就直接在这个 PK 里边先过滤掉这个数据，直接就知道去查某一个 block 下边的某一个颗粒，这个 granularity 就是一个颗粒，是一个颗粒为一个力度.然后整体的所有他的优化，就刚才讲的，他这个细节做的特别好，就是他有很多都是对这个关键数据结构都是量身定做的，然后他整体用的是这种向量化，全面向量化的这种引擎。然后 Pipeline 的并行化，实际上做的也是相当好的，也是基于几篇论文去一起做的。3. ClickHouse 应用场景对于场景来说，大概来就是这几种还有一些比如说包括时序数据库的这种方式也有很多是用在 LT 里但是这里展开，其实这个里可做的方式非常多，比如说有这种 lodo 分析，然后有这种 abtest ，然后包括这个广告里面用的最多的就这种圈人，就相当于各种 tag 去这种整体做圈人的操作，实际上 CK 用的是相当多的。目前来说，这个 CK 的接受度应该也都接受起来了，用的也比较广泛了，大多都是跟 flink 连着用，然后有的时候还用 spark 去做数据清洗之后，然后 spark 的离线数据导入这两个方式，就刚才讲的那些场景其实都有提及。4. EMR ClickHouse 架构这里面是 EMR 做的一些 CK也就是跟一些社区不同的。与社区不同的第一个就是有 In Memory Part 就是刚才讲的很多的 flink 或者是 spark 需要攒批去写入的，但是想打破这个瓶颈也就是相当于按几条或者几十条，就不用让这个客户非常的繁琐，因为客户要是想配十兆或者说20万条还是几十万条，实际上有的时候客户配不清楚，他不知道1万条是多大数据，也不知道每条数据是一个 K 还是几十个 B ，不清楚有多大数据就可以直接用这种 In Memory Part ，在 In Memory Part 里会为你来攒批，攒完批之后会落入。然后这里边有一篇文章，主要是写了做的这个 Flink Exactly Once 事务写入，这个是支持端到端用 flink 做实时数仓的一个写入的。然后这个 Sharding Key 是，正常来说如果有线上运维 ClickHouse 这种经验的话，就知道 ClickHouse 实际上是不能够写分布式表的，如果写分布式表，比如说写到这个 Shard 1里边，那么这个 Shard 1会先落盘，然后这个 Shard 2才会从这个 Shard 1里去 fatch 这个数据，所以说整个会对 Shard 1的磁盘的这种 io load ，实际上是非常高的，所以在前端也就是在 ClickHouse Jdbc 的这一层去做了这个 Sharding Key 也就是对应的 Sharding Key 可以写到对应的 Shard 里边。比如说这里面的 Shard 1，可能“1”这个数字永远就落到这个 Shard 1里了，这个“1”数字不会再随机地落到 Shard 2里。因为有了 Sharding Key 的聚促，相当于他有本地性，那么直接做这个 Join 的时候可以做一些 Join 上的优化，然后再做一些其他的算子上的优化。然后这里支持冷热存储，这个冷热存储就是 CK 可以直接把这些冷的数据给他直接放到这个 OSS 里。还有就是 EMR 的一些通用特性像报警、监控，还有一些扩容的方式。后续会在 CK 里去推几个事。第一个就是 HouseKeeper 去替代Zookeeper，这个是社区2022年的一个重点的方向相当于在 in production 的环境。因为现在已经发布了21.8的版本，实际上就已经有实验性质就是去替代这个 Zookeeper ，但是在生产级别是2022年上半年需要追求的，也会把整个的 Zookeeper 给去掉，因为在 Zookeep里边去做复制的分布式表，实际上是有一些不好的地方，所以要剃掉他。第二个就是做存算分离，就是刚才想讲的这种用这个 OSS 为底座，然后用 cash 去做整个的数据加速层，然后能够得到的是成本的降低，但是在热表上或者说在一些非常想要的这个表上这个性能还不会比原来差多少。第三个就是构建 Front End Server ，因为构建 Front End Server 在社区里没有提到，但是这个做起来是非常好的。一会讲到 StarRocks 架构的时候，可以看到 Front End Server 实际上对整个的架构有一个比较大的帮助的。
-
发表了文章 2022-11-24
Spring Boot2.5 实战 MongoDB 与高并发 Redis 缓存｜学习笔记
开发者学堂课程【5天实战 Spring Boot 2.5：Spring Boot2.5 实战 MongoDB 与高并发 Redis 缓存】学习笔记，与课程紧密联系，让用户快速学习知识。 课程地址：https://developer.aliyun.com/learning/course/780/detail/13692Spring Boot2.5 实战 MongoDB 与高并发 Redis 缓存内容介绍：一、课程对象和目的二、MongoDB 简介三、MongoDB 优点MongoDB 的典型行业案例一、课程对象和目的移动互联网架构结合课程知识进行扩充无论是java、PNP等，很多代码做正式项目时，将代码进行分层（java），便于管理代码，是一个主要职责三层架构：前端UI层或展示层，中间业务逻辑层，代码里写各种业务逻辑，业务逻辑一般指各种订单、会员加多少分，做判断，执行工作，其次是数据访问层，图中DAO，数据访问对象，对数据库或对接数据文件的操作，代码有很多类，不同类负责不同数据源的对接较为普遍的现象，一般都为三层无论是java语言或其他语言，结构都是三层UI或展示层，一般是界面，网页或收集界面，都是用户界面层，后台有接口，通过接口、经过一些逻辑数据代码访问各种数据库，需要情况下访问数据库不论是数据库或是缓存主要目的构建高并发建构：高并发举例：淘宝双11支付订单峰值每秒五十多万，数据库较为恐怖，平时流量达不到，日常支付每秒一道两万，技术架构业务较为平稳。银行、石油石化等一些部门技术迭代较慢，要求、业务较为稳定，动力较小。对于公司来说，在技术上快速迭代，业务在急剧的变化或增长，外界的动力推动技术团队不断提升技术能力。淘宝走的是一个无人走的道路前期的高并发购买的数据库、服务器，价格昂贵且技术封锁或封闭性较强，基本不开放源代码的技术体系，新阶段，银行等其他单位开始转型，走开源路线，开源不一定完全免费但源代码开放，技术可控。很多系统技术可能多个系统并存，淘宝不一定只用My SQL,还有其他系统，共同解决面临的一些问题。如，地铁刷卡机windows系统、XP系统等，每个数据库都是自己擅长的一方面早期数据库存储时，严格定义数据的表，有严格数据类型的定义，各数据之间有明确的关系，有严格的流程。数据库中要保存关系,数据库中再定义表时，无论订单表还是用户表，之间都有关联关系，即外界关联。MySQL等数据库严格体现数据关系，必须提前设计表，之后才能在数据库中保存数据，有严格流程，较为严谨。2007年以后，抖音、微信等诞生在移动互联网时代，APP指的是移动应用，无论是安卓、苹果程序，通过后台接口保存数据，收集中的淘宝或微信APP，查询数据时，通过网络发送给淘宝数据中心数据库，返回各种数据，通过返回查找的各个数据。互联网业务迭代较快，依赖业务竞争国外知识产权保护较好，有核心竞争技术，国内存在产品经理要有品味，格局要大技术移动互联网时代后，传统的 My SQL 数据库，适应需求变化方面较差。如，淘宝，早期使用My SQL做数据库，淘宝APP与PC端收集的数据和存储的数据不同，包括抖音、微信等其他APP，这种搜索平台，都会定位位置，位置信息会根据喜好或周边环境推送相关信息，在PC时代，都是在百度浏览器推出各类广告，范围较广，不精确，现阶段，较为准确，同时也扩展收集其他外部数据。二、MongoDB 简介MongoDB业务场景数据库诞生时，不需要提前在数据库设置严格的表结构定义，希望设计一种简单的轻量级的数据库，灵活的存储各种不同的数据，数据不要求字段数量，可以更改，是一个优势，轻量级，灵活。MongoDB后期也加入很多功能，如缓存、集群等技术架构，走的是他人无法覆盖的路线1.NoSQL排名第一，BAT互联网公司必备2.分布式数据库，3.由C++语言编写，特点是高性能、易部署、易使用、存储数据非常方便,4.旨在为Web应用提供可扩展的高性能数据存储解决方案5.MongoDB由10gen团队所开发，于2009年2月首度推出6.MongoDB开源、跨平台，7.支持Windows、Linux、OS X和Solaris系统8.MongoDB最新版本为4.0，支持跨文档事务三、MongoDB 优点使用MongoDB公司，有明显移动互联网的特点，新浪微博、物联公司等都在使用国产的一些手机通过定位查找，保存时间，保存数据，适应灵活多变的场景四、MongoDB 的典型行业案例互联网、电商、电信、媒体与娱乐、金融与保险、医疗
-
发表了文章 2022-11-24
Ocean Base 存储引擎结构（上） | 学习笔记
开发者学堂课程【从0到1数据库内核实战教程：Ocean Base 存储引擎结构（上）】学习笔记，与课程紧密连接，让用户快速学习知识。课程地址：https://developer.aliyun.com/learning/course/1083/detail/16095Ocean Base 存储引擎结构（上）主要内容：一、LSM-Tree 二、Compassion三、Compaction in Ocean Base 四、总结实际上比较典型的数据库管理系统会包含多个组件，每个组件负责不同的功能。而存储引擎主要是负责数据的存储和查询，提供组件插入、更新、删除、数据、数据加锁、随机读取以及范围查询等操作。许多分布式的数据库能够提供的写入速度是远远超过传统数据库的。故此本节课程将从底层的LSM-Tree 存储引擎作为切入点介绍的策略，进行剖析如此优异的写入速度实现的方法，最后介绍Ocean Base 基于的类型，以及针对一些特别的使用场景因素提出的优化算法。一、LSM-Tree LSM-Tree 全称为Log Structured Merge Tree，结构化合并树，最早在1996年Patrick O'Neil, Edward Cheng等人在论文《The Log-Structured Merge-Tree》中提出，随后在新的数据库引擎中得到广泛应用，例如HBASE 、cassandra 、RocksDB等都选择了LSM-Tree ，oceanBase采用的也是LSM-Tree架构，基于LSM-Tree进行搭建存储引擎。1、B+树与 LSM-Tree目前页面实现存储引擎的两大顶流的数据结构是 B+树与 LSM-Tree，两者之间是有差别的，传统数据库更加青睐B+树，而新数据库则更偏爱LSM-Tree，其实是平衡搜索无数的一种。B+树是平衡搜索树的一种，是为了磁盘搜索而诞生的，一个叶子结点设定为一个磁盘块。B+树的所有的数据都存在叶子结点里面，每次查询或者写入时，都需要从根节点开始搜索到叶子结点，再从叶子结点对应的位置进行操作，即原地更新。传统数据库会将B+树的每个叶子节点设置为一个磁盘页的大小，每次磁盘IO可以加载一个完整的叶子节点到内存中，以此减少IO次数。B+树查询/插入/删除的时间复杂度都是O(logN)。2、LSM-Tree 架构LSM-Tree 的核心思想为将离散的随机写请求都转换成批量的顺序写请求。当有数据写入时，会先存储到Memttable 以及用户的数据日志，此write-log-frozen 机制需要回放数据日志就可以恢复到重启之前的状态。当Memttable 占用内存数据量达到一定预定值之后，Memttable 则会转化成Frozen Memttable ，变成只读状态，冻结的同时会创建一个新的Memttable 进行数据的写入。后台会将Memttable 写在磁盘上，变成一个SSTable 。此过程全部结束之后，Frozen Memttable 与数据日志可以被回收，实际上Memttable 是一个纯内存结构，一般会使用红黑树或者跳表这种有顺序的数据结构，为了便于后续数据的读取并写入磁盘变成SSTable。磁盘上的SSTable全称为sorted string table，是从Google的big table所借用的一个概念。被译为内部有序的磁盘文件，数据是按照rookie递增来排序的,可以使用二分搜索的方式来快速的定位到的数据。磁盘上的SSTable通常会被划分为多个层级，层级的数字越低表示数据写入的时间越临近，例如L0层的数据就是最近写入的，数据的数字越大就表示此数据越老旧。LSM-Tree 是一个Append-Only 的类型，update 与delete的操作都作为一个额外的行来写入。故此rowkey 若发生多次更新，在LSM-Tree 中会存储rowkey 的多个行。LSM-Tree 的查询是先从内存中的Memttable 开始查起，若内存中的Memttable 没有找到rowkey ，再从Memttable L0层、L1层直至LN层，直到查询结束。对于B+树与LSM-Tree已有一定了解，接下来对比两者之间的差别。首先B+树有原地更新与一个电厂块的假设，此使得B+树的数据块是不太适合做压缩的，若对数据块做了压缩会使得原地更新会需要有额外的解压与压缩操作，则会导致更新性能变差。LSM-Tree 是一个Append-Only 类型，将更新写作额外的行，并且SSTable当中的数据没有经常的假设，故压缩就会变得比较自然。二、CompassionCompassion实质是对数据的重新整合，将多个SSTable的数据作为输入，然后进行规律的排序，并输出为一个SSTable， Compassion减少了SSTable的数量，提升了我们查询的性能。但Compassion其实是一个资源消耗特别高的操作，其涉及到磁盘上SSTable的读取与写入，此表明会占用大量IO的代换，并且在读取与写入中会涉及到数据的压缩、解压、checksum 计算以及rowkey 的比较，故此是一个CPU 密集型的操作。并且Compassion 完善之后可能会产生性能的抖动，例如内存中的Memttable 转化成完善的SSTable，则之前对内存Memttable 的查询会变成对磁盘SSTable的查询，故此会使查询耗时延长。为了权衡Compassion 查询提速时以及Compassion 带来的资源消耗，此为业界持续关注的问题。1、Compaction - Amplification不同的Compaction策略是对写放大、空间放大、读放大的一个权衡写放大(Write Amplification)=磁盘写入的数据量/实际的数据量，用户写入一行数据，在LSM-Tree中会触发若干名Compaction，则会导致其他一些数据被读出写入，即原本写入一行数据的IO，就被放大成N倍数据量的IO。空间放大(Space Amplification)=存储的数据量/实际的数据量，由于写入的数据都是Append系列，不是原地更新，故之前的数据不会立刻被清理，相同rowkey的行在多个SSTable中都是存在的，故实际存储的数据量比实际存在的数据量会大得多。读放大(Read Amplification)=本次扫描的数据量/实际返回的数据量，查询需要访问多个SSTable，则会导致扫描的行数比实际返回至用户的行数会多得多，此为读放大。接下来讲解LSM-Tree业界通用的Compaction 策略2、Classic Leveled CompactionLSM-Tree划分为N个Level，每个Level仅包含一个SSTable，相邻的SSTable的大小有倍数关系，通常称之为find out，即为上出。Classic Leveled Compaction触发的条件为某个Level的存储数据量达到阈值之后则会触发一次Compaction，L(n)+ L(n+1) = new L(n+1)，例如下图，当L1层达到设定的阈值则触发一次Leveled Compaction，将L1层的数据与L2层中rowkey range有交集的部分进行 Compaction ，以此得到一个新的L2层的数据。实际上在最差的情况下，此 Leveled 型策略可以达到find out ,即为set 的倍数，并且 Leveled 策略比较容易存在雪崩效应。例如假设在LSM-Tree中，SSTable 数据量都比较接近每一层的阈值时，在L0层写入少量数据，触发了L0层至L1层的Compaction ，使得L1层的数据量超过阈值，此急跌反应可能会导致每个Leveled 都触发Compaction ，此情况是十分严重的。3、Size-Tiered Compaction在此模式里LSM-Tree划分为N个Level，每个Level 包含多个SSTable， several L(n+1) = new L(n+1)。先统计的SSTable 可能会存在一定的交集，故在查询时需要访问此Level 所有的SSTable，这使得查询性能一般。Compaction触发条件是某个Level的存储数据量超过设定阈值，然后将LN层的SSTable 进行Compaction后形成一个新的SSTable 放至N+1层，但并不与N+1层原有的数据进行Compaction。相比于Level 的写放大会更优，但由于查询的SSTable 数据量较多，故读放大较差。实际上Level 模式与Tiered 模式的优点与缺点都是比较鲜明的，但对现实的场景都不适用，故取长补短的混合模型更加适用于存储引擎：Tiered & Leveled Compaction4、Tiered & Leveled Compaction对于层级较小的Level，使用Size-Tiered模式减少写放大问题，因为层级较小的Level 的数据量较小，写入的数据更新（更新的局部性原理）可能性较大，故选择Tiered模式。对于层级较大的Level，写入的数据量比较大、耗时长，不太可能被更新，故使用Leveled模式减少空间放大问题。RocksDB、OceanBase都是选择Tiered & Leveled 的混合模式。5、FIFO Compaction此模式LSM-Tree只有一个Level，故所有的SSTable都放在L0层的一个Level中，所有的SSTable以时间序排列，每次Compaction淘汰生成时间最早的SSTable，此为最简单的Compaction策略，但容易丢失数据，故适合时序数据库这类有时间属性和时间效用的数据。6、Tiered、Leveled 、Tiered & Leveled 总结对比以上介绍了Tiered、Leveled 、Tiered & Leveled 、FIFO 四种Compaction 类型，抛开FIFO 不谈，因为它可能会丢失数据，故此对前三种的Compaction 类型进行总结对比。对比每种Compaction 策略的设定、优势与劣势。Leveled的Compaction 为每个Level包含一个SSTable；Tiered类型每个Level包含多个SSTable，相同Level的SSTable的owkey range可能存在交集；Tiered & Leveled 对层级较小的使用Tiered模式,例如L0层可以有多个SSTable，对于层级较高的使用Leveled ，因为数据量较大，每一层只有一个SSTable。对于Leveled来说，是以写放大作为牺牲，而换取读放大与空间放大的优异表现，代表数据库有RocksDB的Major Compaction；Tiered为写放大比较优异，但由于SSTable 数据量与数量比较多，故读放大与空间放大则较差一些，代表数据库有Cassandra比较早期的SizeTiered Compaction Strategy以及RocksDB的Universal Compaction 。对于Tiered & Leveled 的混合模式取长补短，写放大比Leveled更佳，且读放大与空间放大比Tiered更优，代表数据库为RocksDB默认的Leveled Compaction 以及oceanBase 也是选择Tiered & Leveled 的混合模式。实际上Compaction 策略本身并没有好差之分，LSM-Tree可以根据不同的应用场景、服务的业务场景进行选择最合适的Compaction 策略。可以看出，对于读放大、写放大与空间放大三者的权衡，空间放大是呈现一种伴随状态出现的，即空间放大是由于SSTable 的数量较多，同一个rowkey存储较多的行会导致查询时需要扫描更多的行，因此对应的读放大也会增高。而读放大与写放大是呈现一种对立态势，两者互相拉扯，不能同时达到最优，就像鱼与熊掌不得兼得。 Leveled 与Tiered 都是追求局部的自由，而Tiered & Leveled 混合模式则追求读放大与写放大的平衡。7、墓碑问题墓碑问题是LSM-Tree的经典问题，随着Compaction的执行，相同Rowkey 所有行会进行从新往旧地compact，以此减少空间放大，以下图为例：Key A引出value 值分别为1与1，后续将之UPDATE，将第二个value 值更新为3，此两个行处于不同的SSTable 中，Compaction 之后则会将两行compact 成一行，得到一个最新的value 值为3的最新结果。对于delete 操作来说有一点特别，理论上insert 行与update 行加上一个delete 行，结果为delete 行。实际上所有的rowkey应该被删除，但是由于rowkey 在所有SSTable 都有可能存在，故delete 行就需要将所有的相同的rowkey 行删掉，此delete 行才能被删掉，此delete 行则被称之为墓碑，必须与最底层即LN层进行compact ，delete 行才能被完整删除，以上则为墓碑问题。三、Compaction in Ocean Base 此为Ocean Base 对Compaction 设计，首先介绍LSM-Tree 在Ocean Base 中的设定，与传统的LSM-Tree 相类似，分为内存中的Memtable 与磁盘上的SSTable，Ocean Base 将磁盘上的SSTable 划分为三层，分别为L0层、 L1层、L2层。在L0层使用Tiered 模式，可以允许L0层可以有多个Mini SSTable ，L1层只能有一个Minor SSTable，L2只能有一个Major SSTable。Ocean Base 中的Compaction 分为三种类型，分别为Mini、Minor 与Major。1、Compaction in OceanBase -Mini Compaction内存中的Frozen Memtable通过 Mini Compaction变成磁盘上的 Mini SSTable，是Tiered类型的Compaction，是数据日志的一个 checkpoint。Mini Compaction结束后，其对应的Frozen Memtable和数据log 可以被释放。2、compaction in OceanBase - Minor compaction针对LO和L1层的SSTable，Minor compaction 就是将多个Mini sSTable合成一个，主要目的是减少SSTable的数量、减少读放大问题。当Mini SSTable 的数量超过阈值时自动触发Minor Compaction。Minor 实际上被细分为两类，第一类为L0层>L0层，即多个Mini SSTable 合成一个SSTable ，是一种Tiered 模式。第二大类为L0层->L1层，是一种Leveled 类型的compaction 模式，即将多个Mini 与一个Minor进行compaction 之后生成一个SSTable ，对于两者不同模式的选择取决于Mini 的数据量，当Mini 的数据量较少时使用Tiered 模式 ，当Mini 的数据量较多且Minor 数据量与Mini 数据量相近时则选择Leveled 模式，将所有数据都合成至Minor SSTable 中。3、Compaction in OceanBase - Major compactionMajor Compaction是整个集群选择统一的Major位点，每个分区都使用该Major位点做快照查询，并将查询结果进行持久化生成 Major SSTable。合并触发有三种触发方式:自动触发、定时触发与手动触发。自动触发:Mini Compaction执行次数达阈值，缩减SSTable的数量，降低读放大，故调用一次合并。定时触发:因为合并是一个资源消耗型的操作，故尽量避开在业务高峰期进行合并，通过设置触发时间，在业务低峰期定时触发合并。手动触发:使用命令触发合并。讲解完三种Compaction 触发类型，接下来讲解OceanBase 对于一些特定的业务场景，在领域中做了某些优化算法。4、Compaction 算法（1）、Compaction in OceanBase -全量合并全量合并和HBase与 Rocksdb 的 Major compaction过程是类似，在全量合并过程中，会把当前的Major SSTable数据都读取出来，和所有的 Mini / Minor SSTable合并后，再写到磁盘上去作为新的Major SSTable。此过程是十分消耗 SSTable 磁盘空间的，若非必要则不会使用全量合并。而且在 Ocean Base 中，一个SSTable 实际上是一个宏块的集合，每个宏块则是若干微块的集合，则可以想到，在一个SSTable中若部分宏块旁边的微块没有被修改的情况下，则并不需要完整的数据成型，故提出优化算法，称之为增量合并。（2）、Compaction in OceanBase -增量合并增量合并是相对于全量合并而言，大多数情况下，增量合并只重写发生了修改的宏块/微块，未修改的直接放入新 Major SSTable 中。更进一步，若宏块和微块并没有进行修改，也可以直接放入新的 SSTable 中，故此宏块和微块的重用省去了行解析、编码以及计算列checksum等操作，同时改善写放大问题。（3）、Compaction in OceanBase -渐进合并在执行某些DDL操作时，例如执行表的加列、减列、修改压缩算法等操作后，可能需要将数据重写一遍。但0ceanBase数据库并不会立即对数据执行重写操作，而是将重写动作延迟到合并时进行。数据重写将增量合并回退到全量合并，使得Compaction耗时变长，故提出了渐近合并思想。渐进合并的核心是把数据的重写分散到多次合并中执行，在一次合并中只进行部分数据的重写。以下代码为例：alter table t1 set progressive_merge_num = 60;将t1表渐近合并的轮次设置为60，即一次合并只能重写SSTable 中1/60的数据，当60轮合并执行完毕之后，所有的数据都被重写，以上内容为渐近合并。（4）、Compaction in Ocean Base -轮转合并轮转合并的诞生是为了规避合并对业务的影响多副本轮流执行合并操作，一般来说，合并是在业务的巅峰期进行，但并不是所有的业务都有巅峰期，故在合并过程中为了减少资源消耗、对业务的IO 或者查询带来影响，以此引入了轮转合并，轮转合并介入了Ocean Base多副本的分布式架构。一般情况下，OB会以三个数据副本进行部署，以下示意图为例：当L3副本进行Compaction 时，会将用户的查询尽量放至L1进行执行，当zone 3副本合并结束之后，再将用户的查询导入至zone 3，再由zone 1进行Compaction 。即三个副本轮流进行Compaction ，轮流执行入库的查询操作，故此业务的高峰以及Compaction 的资源消耗就不会放置在同一个副本上。（5）、compaction in OceanBase -并行合并当合并参与的SSTable数据量特别大时，整个合并的过程会非常耗时。算法将整个需要完成的 Rowkey值域按照当前tablet_size划分为若干个子任务，子任务之间可以并发执行，当所有子任务执行结束之后本次合并才算结束。并行合并默认开启，对于数据量大的 Compaction后台自动划分并行任务。四、总结首先介绍了 LSM-Tree 与B+树的对比，然后介绍了LSM-Tree 中的Memttable 、SSTable 、DML模式；第二大块介绍了业界通用的Compaction 策略，分别为Tiered、Leveled 、Tiered & Leveled混合模式 、FIFO，同时介绍了LSM-Tree 的墓碑问题。最后一部分介绍了 Ocean Base 对Compaction的设计，讲解了Mini/Minor/Major Compaction以及对于一些特定场景的优化算法：全量Compaction、增量 Compaction、渐近 Compaction、轮转 Compaction以及并行Compaction。
-
发表了文章 2022-11-23
YoC 基础软件平台应用介绍 | 学习笔记
开发者学堂课程【YoC 基础软件平台应用介绍：YoC 基础软件平台应用介绍 】学习笔记，与课程紧密联系，让用户快速学习知识课程地址：https://developer.aliyun.com/learning/course/59/detail/1077YoC基础软件平台应用介绍内容介绍：一、Yoc的定义、作用二、Yoc的平台框架三、CSI的定义四、低功耗BLE平台五、Yoc的网络框架六、Yoc语音子系统七、Yoc的安全子系统八、Yoc的开发管理九、Yoc平台的国际认证 一、YoC的定义、作用1、定义是集芯片开发系统，AliOS Things微内核，芯片认证质量体系为一体的应用开发平台。2、作用：①为用户提供快速对接处理器和芯片提供基础平台能力；②为用户应用业务的集成提供全栈式融合能力； YoC以芯片开放社区为入口，不断的去吸收外部开发者和芯片厂商的产品需求，开发需求以及生产需求。不断的完善YoC自身的产品开发应用平台的能力，同时也为外部的芯片厂商和开发者提供不断增值的服务。 二、YoC的平台架构中间是AliOS Things微内核，底下可以支持三大主流芯片平台，应用平头哥处理器、five处理器、arm处理器；在硬件之上有抽象层，用芯片加载AliOS Things微内核；在内核之上，是自行开发通用的组件；在组件之上，有子系统的框架；在最底层，用户可以基于子系统的应用框架去开发自己的应用：左侧是开发YoC应用程序、调试生成进项签名所用到的一些工具，像CDK、Emulator等。右侧是质量认证体系里一些常用的认证手段，像CICD、IEC-61508项目管理等；项目会严格遵守IEC-61508的标准。 三、CSI的定义1、定义：最底层的硬件芯片能力的一个抽象。2、全自动化：在搭建芯片IP仓库时，就把需要的芯片IP的驱动全部都以芯片SDK快速开发的方式定义出来，包括IP的技术文档手册、测试用例等等，在开发完之后，快速的把芯片SDK输出到OCC芯片开放社区上。3、优势：①代码符合IEC-61508的工业标准；②针对嵌入式的代码密度优化；③上千条测试用例保证代码质量；④对接AliOS Things操作系统； 四、低功耗BLE平台最底层是硬件抽象层，用CSI的接口去抽象整个的硬件平台能力；在这之上搭建了一层内核服务层；再往上是服务层的一些应用；最上面就是用户的应用程序。一共四层，每一层对接都是在Kernel Service Layer这一层，完全的调用底层的CSI接口，所以用户只要能够在这一层做到无缝的驱动开发对接，那上面的这三层驱动服务和应用程序，都可以做到无缝的迁移和使用。五、Yoc的网络框架1、支持多种的联网方式：模组的联网、外部的WiFi芯片、WiFi集成芯片。2、移植层：针对不同的联网方式，可以选不同的移植层模块，这样用户就不用被其他网络层困扰。3、标准AR：支持标准的上网AT命令。六、Yoc的语音子系统语音子系统的框架基于AUI Service，通过AUI Service连接AI云平台，像天猫精灵云平台、 MIT云平台、科大飞讯云平台；也会支持低功耗的特性以及第三方AI算法应用。只要基于语音子系统框架做相应的移植，就可以在Yoc把语音子系统运行起来。七、Yoc的安全子系统1、安全硬件抽象层对硬件安全IP 提供统一的驱动接口，消除不同芯片差异；2、安全基础组件组对应不同的安全场景，形成统一安全基础库，包括：密码计算、存储、权限管理；3、安全应用组件层具备面向场景的安全组件，简化安全终端设备开发难度；4、安全终端设置基于安全子系统，可快速开发具备安全特性的终端产品；如今互联网的安全等级并不一致，通过安全基础组件，设定一套多层次安全客户端的接口，可以灵活的适配不同安全等级的芯片平台，从而让位于安全基础组件上层的安全应用组件以及安全终端设备的开发变得简单。 八、Yoc的开发管理：使用CDK下载组件SDK.用CDK从云端下载 Yoc组件，通过yoc的组件的开发测试，允许用户把应用组件部署到私有云上。整个组件的开发和管理，依据工程组件YAML的配置决定组件仓库地址，从而通过CDK拉取位于外网上任何地方的组件。九、Yoc平台的国际认证1、yoc软件平台通过的德国 tuv413功能安全认证完全符合IEC-61508功能安全认证标准。 2、yoc平台开发的蓝牙系统通过了SNG BQB国际认证这证明Yoc平台有很高的安全可靠性开发者在选择物联网操作系统的时候，可以多关注安全可靠性。Yoc平台更是具备了安全可靠性的特性，给开发者提供了更好的选择。
-
发表了文章 2022-11-23
PolarDB 安装与配置 | 学习笔记
开发者学堂课程【PolarDB for PostgreSQL 开源人才初级认证培训课程：PolarDB 安装与配置】学习笔记，与课程紧密连接，让用户快速学习知识。课程地址：https://developer.aliyun.com/learning/course/1077/detail/15550PolarDB 的安装和配置内容介绍：一、创建用户与环境配置二、系统内核参数配置三、PolarDB 11.9安装四、创建数据库、配置与使用PolarDB 安装文档上也提供了安装的过程，但是，第一次接触需要花比较多的时间去适应，这节课，会讲解安装的整个过程，能够让用户方便的把 PolarDB 环境把部署起来，可以节省一些时间。这节课的内容包括这4个部分，首先是创建用户与环境配置、系统的内核参数、 PolarDB 的整个安装过程、安装完成后的使用方法，用这种方法可以快速的去部署 PolarDB 。一、创建用户与环境配置1.Github 账号注册因为 PolarDB 的安装软件是放在 githup 上，所以在下载软件时，需要 SSH 的认证，所以在安装之前先要到 githup 网站上去注册一个账号； http://github.com/ ，注册账号后要记住用户名以及邮箱。2.Postgres 用户创建与配置虚拟机安装 PolarDB 时，可以用 Postgres 用户进行安装。为了更好的使用Postgres ，需要在 Linux 系统上用 Postgres 用户进行安装，在安装时需要调用 sudo ，一般情况下系统都安装了 sudo ，如果没有安装，需要用 ，那么安装完后，需要用 root 用户执行以下命令。执行之后，需要注意目录的权限，一般情况建议在默认在 home 目录下建目录正常情况目录的属主是 postgres ，检查下图中的第二步，如果已经是，就不用执行这一个命令。之后再继承环境变量，上图第三步，最后再配置 sudo ，最后两步命令完成即可。3．配置 git 下载 PolarDB 所需环境需要在 github 里安装软件，首先下载 git ：yum install -y git安装完后需要添加登录的用户名和邮箱，可以用命令： git config –global user.name’xxx’ ，添加在 github 上注册的用户名，邮箱用： git config –global user.email ‘xxx@xxx.com’ ，用这一个命令可以添加邮箱，最后用： git config –list 查看是否添加成功，如果添加成功，用这个命令查询时，可以看到下图结果。二、系统内核参数配置1.产生 Postgres ras 密匙如果要在 github 上添加SSH ，需要 rsa 密钥，密钥是在 Linux 主机上产生的，添加 ras 密钥后面一路回车即可，执行完命令： $ ssh-keygen -t rsa -Cxxx@xxx.com” 后，把查看到的密钥填到下一步 github 的ras 密匙中：$ more .ssh/id-pub ，产生完后，查到的密钥要粘贴到 github 配置中，密钥不需要输入密码，只需要一直回车就好。回车完成后，在后面加入： ssh/id_rsa.pub ,下面就是 rsa 密钥。2. github 设置 ssh 密钥在账号里设置 ssh 密钥在 github 里，配置用户的设置，从 setting 进去，如下图。之后，在所有的设置里选择： SSH and GPG keys 这一个配置。选择 SSH 配置以后，在配置界面输入 rsa ，把刚刚看到的 rsa 密钥，粘贴进去，再选择 Add 即可，如下图。三、PolarDB 11.9安装以上步骤完成后，就可以使用命令开始下载 PolarDB 软件：$ git clone -b POLARDB_11_STABLE git@github.com;ApsaraDB/PolarDB/PolarDB-for-PostgreSQL.git 可以用 PostgreS下载，下载时间会比较长，完成后进入到 $ cc PolarDB -for-PostgreSQL 目录下，再用 sudo 去执行 install_dependencie.sh 这一个脚本，执行后这个脚本会下载 PolarDB 在安装过程中需要的系统软件包，下载完后需要开始编译。1.PolarDB 软件编译与部署编译之前需要编译部署需要进行 source ，因为上一部分下载的脚本里会往文件里添加环境变量，如果没有更新环境，直接编译可能会报错，要注意细节。更新完成后，重新到目录，执行编译：$ cd PolarD-for-PostgreSQL$ ./polardb_build.sh脚本编译完成后会初始化实例，一个数据库，部署完成后，需要进行实例检查和测试，确保部署正确。执行数据库，如果会返回下图的结果，说明部署已经完成了。四、创建数据库、配置与使用1.配置 .bash_profile为了方便之后的使用一般会在 postgres 后添加环境变量，添加时注意首先添加 PG HOME ，是软件安装的路径。注意有一个 tmp ， tmp 是阿里专门开发的文件系统，可以理解为一个共享存储系统，和 oracle rac 共享存储一样，将来这一个节点上的存储可以被多个节点访问，其他节点在启动实例时，无需将文件拷贝过去，直接访问节点上的数据即可，可以理解为共享存储。将 PGDATA 指定到路径下，再声明访问的端口：export PGPORT =5432，PG用户登录时用户名、主机和数据库，如下图。export PGUSER=POSTGRESexport PGHOST=127.0.0.1export PGDATABASE=postgres了解后就只需要 psql 就可以登陆到PolarDB 数据库，非常方便。在实例这一级，对用户是信任的，所有不需要提供密码。
-
发表了文章 2022-11-23
2.1连接器功能介绍｜学习笔记
开发者学堂课程【低代码认证-第二章:连接器相关课程：2.1连接器功能介绍】学习笔记，与课程紧密联系，让用户快速学习知识。 课程地址：https://developer.aliyun.com/learning/course/1008/detail/150582.1连接器功能介绍内容介绍：一、课程背景与课程目标二、连接器功能介绍一、课程背景与课程目标三、首先看一下本章的课程背景。钉钉宜搭强大的集成能力。也能够打破钉钉宜搭与企业自由的系统数据壁垒，实现跨应用间的数据互通。本章课程在资产管理的场景下，通过钉钉宜搭自定义连接器。打造智能资产管理应用，能够有效的提升资产管理效率。通过资产管理的实践，才可以掌握自定义连接器的使用。了解了课程的大概情况后，看一下本章的学习目标。本章的学习目标有，了解连接三方资产管理系统的背景诉求。掌握连接器基础功能，掌握连接器工厂的开发管理。可以独立钉钉宜搭建连接第三方系统应用。二、连接器功能介绍接下来学习连接器功能介绍。这里的连接器功能分别是用来集成第一方和第三方系统的，本章主要学习集成第三方系统，先来看一下集成第三方系统的背景诉求与优势。（1）集成第三方系统的背景诉求与优势（2）背景诉求是，目前有很多企业有较多的数据沉淀在钉钉宜搭以外的其它业务系统当中，如传统的ERP、CRM、HRM 系统等。使用钉钉宜搭搭建系统后，如何将系统之间的数据打通成为了企业关注的问题。使用钉钉宜搭搭建的优势是钉钉宜搭有强大的集成能力。不仅能为企业量身定制更为贴合业务的系统，还能打破钉钉宜搭和现有系统的数据壁垒，大幅度的提升效率，节约成本。那么使用钉钉一搭总共有哪几种方式可以去集成三方系统呢？（3）连接三方数据传输的方式第一种 OpenAPI 是对外提供业务开放的接口，通过服务回调和 OpenAPI 的结合使用，可以满足大部分钉钉宜搭与三方系统业务集成的需求。第二个是自定义连接器。通过集成自动化当中的自定义连接器。当然这里包括 HTTP 连接器和 Faas 连接器能够完成在钉钉宜搭页面当中调用外部数据源接口的功能。第三个是服务回调，服务回调是后端发起的 HTTP 请求，主要功能为数据同步，数据校验和动态获取审批人。那么首先来看一下 open API 的调用说明。在钉钉的开放平台上，提供了钉钉宜搭的 open API，以及如何去调用钉钉宜搭接口的文档。钉钉开放平台的直达链接在这里在使用手册当中也可以去找到的直达链接，然后去看这些调动的说明。OpenAPI 总共它的一个调用的方式如下四个步骤，首先会创建一个应用，这里创建一个钉钉应用。支持创建企业内部应用和第三方企业应用。然后第二步去添加接口调用权限，因为在应用创建后，会默认只开放登陆和消息通知的接口和调用权限，如果想要去调用其它的接口，那么就需要根据自己的需求去添加对应的接口权限，当然这里的添加接口权限也是在的直达地址里面可以去找到，然后去进行申请。第三步是获取应用的 access token，这里的 access token 相当于是身份凭证。在调用接口时，可以通过它来去鉴权调用者的身份。然后第四个步骤是调用服务端的接口。这里的服务端接口需要使用的上一步骤的 access token，然后去调用钉钉宜搭的接口。在开放平台当中，提供了 Java 、PHP、Python、 NET 、SDK 供开发者使用。再来简单了解一下自定义连接器的调用说明。首先是创建一个自定义连接器，这里会来到连接器工厂当中去选择 HTTP 的自定义连接器。创建完成之后，在这边去集成自动化，也就是应用的集成自动化当中去选择出发方式。如图片所示选择表单出发，然后这里可以去选择对应的表单。选择完成表单后，点击确定。进入到的页面里面，先去配置它的一个触发方式，之后去选择自定义连接器。是它的一个简单的一个调用的步骤，详细的步骤会在下面进行一个讲解。最后来看一下服务回调的调用方式。服务回调首先要先在宜搭平台当中去进行服务注册，但是点击新增服务。然后去选择调用的接口，还有接口所需要的参数，在服务注册当中，也就是对的接口做了一个预设，比如说它要传什么样的一个参数。它的接口，类型是什么样的，做一个预设，然后回到的表单页面当中。在这里会有一个服务执行。去点击它，在这里就可以去配置服务回调。比如说刚才是配置了数据同步，然后在这里第三方服务当中，就可以去找到数据同步的这一个服务注册，然后下方的参数一参数二，就是刚才去配置的这样的一个参数。（4）服务回调通常是用作数据同步数据。数据校验和动态获取审批人。了解了三种调用方式后，来看一下它们之间的差异化。（5）连接三方数据传输的差异化（6）这里 open API 和自定义联系器服务回调的不同是，open API 是外部去调用钉钉宜搭的数据，而自定义联系和服务回调，它们都是宜搭侧去调用第三方系统的接口。那么使用外部去调用宜搭的数据就适用于第三方系统未开放的这样的一个接口。并且使用 open API 可以去读取和传递第三方的数据，那么自定义连接器和服务回调，它们都是从钉钉宜搭侧去调用三方系统的这样的一个接口。所以它适用于第三方系统开放接口，这样才可以在钉钉宜搭侧去进行调用，当然自定义连接器可以读取和传递第三方数据。服务回调只是可以传递不可以去进行读取。自定义连接器还有一个优点，就是它可以实时地进行数据同步，服务回调就会有一定的延时性，所以它有延时数据同步的这样的一个差异化。那么本章课程主要学习的是连接器的调用，所以首先来了解一下连接器。（7）连接器介绍（8）连接器能够轻松的实现的钉钉宜搭与三方系统之间的数据互联互通，通过数据操作的节点的配置和编排，业务人员不需要编写高级函数和代码。钉钉宜搭是提供了几种连接器的，这里主要来说一下一方连接器和自定义连接器。一方连接器是钉钉宜搭接入钉钉一方连接器。包括工作通知、群通知、待办任务等等，在集成自动化当中选择连接器。钉钉宜搭官方应用就是一方连接器。可以直接去进行一个集成，不需要再去连接器工厂当中再创建一个自己封装好的一个连接器。它可以直接去进行使用而自定义连接器是支持企业开发的一个自定义连接器。包括 HTTP 连接器和 Faas 连接器。这里主要讲解的是 HTTP 连接器，它可以实现钉钉宜搭与其它三方应用的资源整合能力和业务衔接。（9）自定义连接器介绍自定义连接器它的主要功能是需要打通企业存量的系统，也就是说企业内部正在使用的系统，那么就可以通过钉钉宜搭连接器工厂去创建连接器，去连接用户自定义接口，当然接口需要是对外开放的。下图就是的一个连接器工厂。在这里面已经创建了一个应用当中会使用到的连接资产管理系统的这样的一个自定义连接器。下面来对自定义连接器整体的配置步骤进行一个讲解。首先第一步要进入到连接器的一个创建入口，也就是连接器工厂，这里要进入到钉钉宜搭的工作台，然后在这里，也就是设置里面去进入到当前页面，然后选择到连接器工厂，这里面是只有管理员才有这样的一个权限，如果没有连接器工厂，说明还不是管理员。进入到页面之后，可以去进行自定义连接器的创建，选择创建连接器，在右侧弹窗当中选择 HTTP 的自定义连接器。输入连接器的一个名称，然后点击下方的一个确定。当然这里面的一个详细的连接器工厂的配置，会在第二小节讲解到，下一个步骤是在集成自动化当中去选择连接器进行配置。选择表单事件出发。然后去新建一个连接器节点，在这里面去选择宜搭自定义的一个连接器。也就是刚才配置好的连接资产管理系统的一个自定义连接器。配置完成之后，下一个步骤是选择执行动作，去选择鉴权模板。当然，如果这里没有去配置鉴权模板，也可以去点击。然后下面会告知没有鉴权模板，会直接新建一个鉴权模板，跳到鉴权当中进行配置。配置完成之后去选择的执行动作。最后是参数的一个配置。这里的参数可以看到上面一个节点是 groovy。因为自定义连接器，它的参数是一个复杂的一个参数格式，所以在上方通过 groovy 去进行配制，返回正常也就是当前接口所需要的一个数据格式之后，在配置执行动作当中，也就是在参数里面去选择到 groovy 返回的数据。在字段当中选择连接器groovy 返回的这样的一个字段去进行配置，这是参数配置。本小节介绍了连接器的功能和它大致的一个配置方法。
-
发表了文章 2022-11-22
阿里云视频直播服务介绍｜学习笔记
开发者学堂课程【场景实践 - 云端搭建直播点播系统：阿里云视频直播服务介绍】学习笔记，与课程紧密联系，让用户快速学习知识。 课程地址：https://developer.aliyun.com/learning/course/513/detail/6848阿里云视频直播服务介绍阿里云视频直播服务介绍1、阿里云视频直播服务视频直播服务 (ApsaraVideoLive) 是基于领先的内容接入与分发网络和大规模分布式实时流媒体转码技术打造的音视频直播平台，提供便捷接入、高清流畅、低延迟、高并发的音视频直播服务。多终端多平台，多终端采集和播放 SDK，云端同步技术，多终端同步播放行业化成熟的行业解决方案，覆盖几乎所有的直播应用场景全球化全球1000+节点，分布 60 多个国家和地区，覆盖六大洲安全URL 加密，视频加密、防盗链多种安全防护，减少盗播，录播风险提供 web 控制台 API 和软件开发工具包，用户可以通过它们去使用管理视频直播服务，也可以与自己的应用服务来集成。所有的服务都是按量付费，服务能力自动伸缩，用户可以告别复杂的架构设计和编程开发，维护成本几近于零，可以专注于业务逻辑的实现跟最终用户体验的提升。阿里云视频直播服务是一个完整的一站式的解决方案，提供从推流到转码、分发到播放的全套的技术解决方案，提供上行码率的自适应窄带高清、转码、截图、录制、值移等功能和服务。多终端适配不放观看体验，提供多平台多终端的采集 SDK 和播放SDK，覆盖了包括安卓、 ios 等各种的移动设备，以及 PC 端跟网页端，适配市面上绝大部分的机型，包括电视跟机顶盒等等，并且采用云端同步的技术，多端的播放可以同步进行，用户是可以达到无缝观看的体验。第二个特点是行业化，场景化，因为是成熟的行业解决方案，覆盖了几乎所有的直播应用的场景，阿里云为用户提供了电商、娱乐、在线教育、游戏等各行各业的直播解决方案。第三个特点是全球化，阿里云在全球有1000 多个直播节点，在国内也有 1000 多个直播间，覆盖了全球主流国家用户的直播业务，出海毫无压力。第四点是安全包括 url 加密，视频加密以及防盗链多种安全的防护，减少导播录播的风险，保障客户最大的利益。同时保存也是安全存储在 OSS 上面提供了多重的安全保护。2、视频服务流程Step1: 直播前准备登录控制台开通服务添加直播域名 Cname 绑定 配置鉴权Step2: 推流获取推流地址获取鉴权后推流地址 推流软件配置 推流Step3: 播放获取播放地址Web 页面播放VLC 播放视频服务的使用流程比较简单分成三个阶段来操作。第一阶段直播前的准备操作，首先是登录阿里云的控制台来开通服务，然后进入直播服务的控制台就可以添加直播域名。要注意一下直播域名需要进行备案审核的，只有审核通过以后才可以使用，没有经过备案的域名必须先进行备案，域名配置成功以后域名会自动配置好 CDN 直播加速的功能，域名进行绑定之后可以使用直播加速的功能。健全的部分取决于用户是否希望进行加密的直播，如果有需求再去做相应的配置。第二阶段是推流阶段，直播操作可以使用第三方的软件，比如 ODS 或者是 MPG 之类的软件，都可以将健全之后的推流地址拷贝到推流的播放器，可以通过控制台去获取播放地址，进入到自己的网页中去，也可以使用 SDK 的第三方播放工具进行播放，方式有多种多样同时可以看到胶片的下半部分，在推流上来之后很多的工作呢，比如像转码，同步录制，内容截图审核，加速分发等操作都被阿里云的直播服务给封装起来，用户可以不用关心里面的实现细节，只需要在控制台进行相应的点击页面按钮就可以，非常的方便。3、服务架构简介直播的服务架构基本上分成推流端、直播中心跟播放端三个部分。架构有几个主要特点，首先是有强大的主站系统、计算能力跟网络能力以及存储的能力。对于直播业务来讲这三个能力非常重要，是一个比较重要的挑战。第二个特点是 CDN 产品因为分发对接的是 CN，所以具备有接收移动端，PC端 跟专业设备直播推流。第三个特点是方案提供了直播推流和播放 SDK，支持多终端的播放，手机、平板、电视都可以以及多种媒体格式跟多种清晰度都可以自己来设置。第四个特点是方案对接的是弹性伸缩的产品，可以支持计算能力和带宽的弹性伸缩，以及可以及时的应对突发的访问量。对于视频是可以边缘节点就近推流可，以实现首屏秒开、多项优化，实现直播的低延时和低卡顿，还具备媒资存储，切片转码，访问鉴权，鉴黄鉴恐，内容分发加速的能力，是一体化的解决方案。同时提供窄带高清的转化能力，可以有效地节约用户的带宽成本，在推流端的部分上面写着 HTTP DNS 最近推流以及多 BT 中心推流，因为直播服务提供了两种推理的方式，一种是传统的中心推流的方式通过 BGP 线路将视频流直接传输到直播中心进行内容分发，由于阿里云机房本身是 BGP 多线接入的，所以速度跟质量也不会差。另外一种更优的方式是边缘推流的方式，优先将用户的视频推流至最优的 CPN 节点，优先将流数据调动至距离用户最近的最优决定，然后通过阿里云的智能调度系统将数据快速传输到直播中心进行内容分发，保证用户访问的都是最佳的上行网络，减少因为上行传输带来的卡顿、码流缓慢等问题。4、服务方案特性灵活易集成（1）支持 Android，iOS，PC 端;（2）使用 RTMP 标准协议推流，提供多种码率和格式的转码配置;（3）完善的直播 SDK 接入文档和 API 说明，最短4小时接入直播;全面的解决方案端到端的一体化解决方案:（1）直播流推送，直播流转码，分发;支持直播码率自适应;（2）播放器，美颜功能;（3）直播互动，低延时，服务端集成;（4）防盗链，视频加密;高并发支持（1）千万级直播并发能力;（2）500+就近分发节点;（3）十万级直播聊天室;专业服务（1）大客户支持服务;（2）24 小时工单反馈系统;（3）7*24 小时售后电话支持服务;首先是灵活易集成，支持多种客户端的平台，转码的模式十分的丰富，阿里云提供了完善的 sdk demo，用户可以很快就可以完成接入，其次它是一个端到端的一体化解决平台，功能非常的强大。第三是高并发的支持，可以做到最流畅的延迟高并发，可以称之为是业内最低的播放卡顿率，提供全网最流畅的直播观看体验，使用最优质的 BGP 机房和带宽来降低直播的延时，保证直播的实时交互，千万级的直播并发能力，可以动态地扩展直播的技术架构，来护航用户的直播业务。最后是专业的服务，用户可以通过工单和电话来获取帮助，大客户还有专属的专门服务来支持。5、直播流接入、转码、分发推/拉流（1）推流使用标准的 RTMP 协议;（2）拉流支持 RTMP，HTTP-FLV, HLS 协议;端支持 Android，iOS， PC 端直播流推送转码（1）直播流码率，可配置区间为 500Kbps~2.5Mbps，默认标清码率为 750Kbps，高清码率为 1.5Mbps（2）视频分辨率，可自定义，默认是标清为 480P，高清为 640P;自适应SDK 可根据网络情况动态调整上行传输码率分发500+节点数，覆盖所有省份和主流运营商;主要是介绍转码的功能，是为多媒体数据提供转码计算服务，已经利用弹性和高可扩展为它的重要特点，帮助用户将存储于 OSS 的音视频转码成适合在各种平台，比如 PC 或者是电视或者是移动终端上可以播放的格式。媒体转码服务是基于阿里云的云计算服务构建的，改变了以往进行转码的时候需要自己去购买搭建，管理转码的软硬件等等高昂的投入，以及配置优化，转码参数适配等等复杂性的问题。同时借助云计算服务的弹性伸缩的特性，可以按需提供转码的能力，从而最大限度地满足业务的转码需求，而且避免资源的浪费。媒体转码服务包含了向外包公司还服务 API，以及软件开发工具包 SDK 几个部分，用户可以通过使用它们来完成转码服务，也可以将转码的功能集成到自己的应用和服务中去。配合阿里云自主研发的窄带高清功能，可以对视频中的每一个场景、动作、内容、纹理方面进行智能分析，保证在相同的画质比下码率更低，一定程度上也可以降低带宽的成本。近期阿里云对于载带高清的功能进行了升级，在窄带高清的2.0版本中通过人眼视觉的模型，将编码器的优化目标从原先经典的保真度最高，进化到了主观体验，凭借阿云独有的算法，突破了现在视频编码器的能力上限，在节省码率的同时也为用户提供更好更清晰的观看体验。6、直播安全URL 加密URL 鉴权功能是通过阿里云 CDN 加速节点与客户资源站点配合实现的一种更为安全可靠的源站资源防盗方法。（服务过程的各个阶段都可以支持个健全，比如对推进健全，对直播流进行管控，对播放健全都是可以支持的）防盗链防盗链功能基于 HTTP 协议支持的 Referer 机制，通过 referer 跟踪来源，对来源进行识别和判断，用户可以通过配置访问的 referer 黑白名单来对访问者身份进行识别和过滤，从而限制 CDN 资源被访问的情况。视频加密可对码流进行加密，通过 SDK 使用特殊的播放器播放。适合于对内容需要保密的场景。（不适用于普通第三方播放器）7、视频直播通用架构提供便捷接入、高清流畅、低延迟、高并发的视频直播解决方案解决方案优势CDN灵活易集成端到端一体化解决方案千万级直播放并发直播移动监控支持最高性能 秒开:<1秒高并发:万路直播流低成本:智能转码 8、电商视频直播架构视频直播过程中边看边买的解决方案解决方案优势自适应码率推流多路视频转码鉴黄低延时直播直播导购定向营销支持最高性能日活:1000万并发: 100万秒开: 1-3秒电商视频的直播架构，边看边买是在视频直播过程当中，由明星或者一些网红通过现场亲身示范的方式，全方位来展示商品的信息，进而去影响用户的决策，来拉抬消费提升消费。比如阿里巴巴的天猫直播，是基于架构来为数亿的用户来提供服务的。
-
发表了文章 2022-11-22
阿里云视频点播服务介绍｜学习笔记
开发者学堂课程【场景实践 - 云端搭建直播点播系统：阿里云视频点播服务介绍】学习笔记，与课程紧密联系，让用户快速学习知识。 课程地址：https://developer.aliyun.com/learning/course/513/detail/6845阿里云视频点播服务介绍阿里云视频点播服务视频点播 (ApsaraVideofor VoD，简称 VoD) 是集视频音视频采集、编辑、上传、自动化转码处理、媒体资源管理、分发加速于一体的一站式音视频点播解决方案。快速接入 易用的控制台轻松接入服务，便捷的 SDK&API 满足定制开发需求 短视频 SDK 领先内业的产品级 SDK，提供强大的短视频拍摄和编辑能力节约成本 按量付费，服务能力自动伸缩，通过窄带高清技术最高降低30%带宽 安全保障 成熟的视频加密播放技术，灵活的防盗链机制，7*24 小时的服务支持。构建在阿里云强大的基础设施服务之上，可以借助灵活可伸缩的存储以及高质量的视频转码处理技术，还有稳定快速的内容分发服务 CDN，帮助企业和开发者快速搭建安全弹性可定制的点播平台和应用，同时阿里云作为国内领先的短视频服务商，阿里云的短视频 SDK 也提供了视频录制、导入裁剪、压缩视频、特效、编辑等功能，同时也具备美颜、人脸识别、ar 贴纸、变速录制、实时混音、实时滤镜等等几十项市面上主流的短视频功能，用户可以根据自己的需求和业务场景来选择低成本的基础版和标准版，快速的在 app 中集成短视频的功能，可以选择拥有更强大视频编辑功能的专业版，通过自行定制交互界面，充分与业务相整合，快速的实现差异化的短视频业务所有的服务都是按使用来付费的，服务能力是自动伸缩的，让用户可以告别复杂的架构设计和编程，开发维护成本几近于零，使用户可以专注于业务逻辑实现以及最终用户体验的提升。2、一站式的视频点播解决方案图片是阿里云上的视频点播参考的架构，还是相对比较复杂的，架构具有一定的难度的。因此为了让用户更快更便捷的部署视频点播业务，阿里云推出了视频点播服务，vod 服务。视频点播服务是集音视频的上传转码，媒资管理，分发加速于一体的一站式解决方案，借助海量的存储可以灵活可伸缩，然后也可以通过 CDN 来进行内容加速的分发，帮助用户快速的搭建一个安全，弹性高，可定制的点播平台。点播应用支持快速搭建，用户可以在短时间内几乎以零代码的方式完成常见的云端音视频处理的，流程的配置文件上传地址就可以自动的执行。所有服务是按量付费的，几乎不需要维护，阿里云的视频服务提供端上传的功能自定义。工作流高可定制转让对用户十分方便，同时也提供了一些专有的技术，比如像窄带高清的技术，提供高画质的码率，自适应转码输出，同时强大的基础设施可以使用户跨运营商，跨地域，全网覆盖，高安全，高可靠的云存储，来保证海量的音视频文件可以永久可靠的存储。3、服务架构简介因此可以看到通过阿里云的视频点播服务，极大地降低了用户搭建点播平台的门槛，对用户来说只需要进行简单的配置以及购置简单的视频采集设备，可以在短时间内以零代码的方式来完成常见的云端音视频处理的流程配置，非常方便。4、服务方案特性视频点播服务媒体工作流，支持截图、转码、转封装、水印、加密、剪辑等功能，使您可以快速、灵活、按需搭建云端音视频处理流程，音视频上传完毕后自动执行处理流程数据分析:用户会对视频发生点赞，喜欢，收藏，分享，观看等行为，将用户对某个视频产生同一行为的用户进行关联分析建模。当某个用户看了某个视频，而相关联的好友用户没有看过该视频的话，就会在该用户观看视频播放器的下方进行推荐阿里云视频点播服务可以对视频进行监播，延迟设置等手段来保证播控安全使用阿里云视频点播服务中的鉴黄功能可以协助用户做内容审查转码以经济、弹性和高可扩展的音视频转换方法将多媒体数据转码成适合在 PC、TV 以及移动终端上播放的格式，常用于音视频网站、在线教育、金融直播、电商直播等多种场景窄带高清技术，承载着阿里巴巴对视频体验的极致追求，即使片源清晰度不足，即使网络带宽有限，通过窄带高清处理，也能提供高清晰度甚至高帧率的视频服务。5、海量存储的基石：OSS对象存储服务 (Object Storage Service，简称OSS) 是一种面向互联网的分布式存储服务，具有海量安全、高性能、高可靠性、低成本的特点。OSS 非常适合用来存储大量不同大小、格式的非结构化数据，比如视频、图像、日志、文本文件等。单个数据的大小从 1 字节到 48.8T，可以存储的文件个数无限，从而给互联网应用提供海量的存储能力。稳定服务可用性高达99.9%系统规模自动扩展，对外服务不受影响数据三重备份，可靠性达到99.99999999%安全多层次安全防护和防 DDoS 攻击多用户隔离机制提供访问日志有助于追查非法访问大规模、高性能存储容量无限扩展请求处理能力弹性增加多线 BGP 网络确保全国各地访问流畅对于视频点播业务首当其冲的是海量的数据存储，所以在存储方面视频点播解决方案继承了对象存储服务也是 oss ，来提供海量、安全、高可靠的云存储服务。它是一种面向互联网的分布式的存储服务网，具有海量存储空间，无上限高达十个 P，然后安全是在云端的体系保护之下，天然具有防 OOoS 攻击的能力以及高性能，高可靠因为它数据是三副本保存，自动冗余存储数据一旦发现错误或丢失，可以从另外的备份中瞬间还原回来，所以可靠性非常的高。使用 OSS 的用户可以通过网络随时的存储和调用包括文本、图片、音频、视频在内的各种非结构化的数据。在视频点播服务当中用户可以通过视频点播控制台，或者使用 IOS、安卓等等 SDK 工具进行文件的上传，支持分片上传、断点续传、批量上传，可以直接使用 OSS 后端的根据。6、加速分发的利器： CDN阿里云 CDN 服务，将源站内容分发至全国所有的节点，缩短用户查看对象的延迟，提高用户访问网站的响应速度与网站的可用性，解决网络带宽小、用户访问量大、网点分布不均等问题内容分发至全网，跨运营商、跨地域目前提供如下几个基本服务:静态内容(包括图片，html，JS CSS 静态文件等)加速服务下载文件加速服务支持 OSS 存储文件加速服务在分发方面方案也继承了 CDN 内容分发网络，它是跨运营商、跨地域的全网覆盖的网络加速服务，支持千万级的并发播放以及灵活可定制的防盗能力。CDN 是建立在承载网之上，由分布在不同区域的边缘节点的服务器集群所构成的一个分布式的网络，主要是用来帮助用户做分发的加速，来替代传统的以外围中心的数据传输模式反过来的方式，将原内容发布到边缘节点，然后配合阿里云精准的调度系统，将用户的请求分配到离它最近的地方，最适合它的节点，使用户可以以最快的速度去取得所需要的内容，可以解决网络拥塞的情况，提高用户访问的响应速度。简单来说是把数据放到距离用户最近的地方，让用户在拉取静态资源的时候访问路径最短，耗时最少，所以体验就会更好。具体到视频点播业务使用 CDN 一方面极大地降低了用户的带宽成本，另一方面因为视频都缓存在离用户最近的地方，也极大地提升了用户观看的体验更流畅度。7、视频点播的通用解决方案视频点播解决方案海量视频数据存储、百万用户同时在线的吞吐能力、更低延时的用户观看体验、高可伸缩的峰谷业务压力系统解决方案优势多终端上传高可定制的媒体转码智能视频模版分析集成消息队列和通知性能易用:0代码安全:永久存储灵活:弹性伸缩视频点播业务场景有介绍视频音视频的上传，然后转码处理、媒资管理、分发加速于一体，是一站式的音视频点播的解决方案，让传统企业可以轻松的使用视频，为自己的业务运营推广的发展带来新的助力。方案有几个特点，首先是专业的媒体处理可以对音视频处理设置不同的规则，基本不用开发，简易的配置转码、水印，媒体工作流所见即所得，音视频文件上传之后就可以触发媒体工作流的转码流程，不需要进行额外的任务调度。另外是所谓的带高清的转化功能，还可以节省带宽至少20%以上。第二个是海量存储，图片根据冷热数据进行分级的存储，比如冷数据采用 MNS 归档存储服务满足管控的要求，需要保存更长的时间，一般是两年到三年，可以降低视频存储的成本，相对应的数据通过 OSS 内网进行访问，满足万路高清视频的写入，采用多层错误重试的方式有效的屏蔽底层的网络错误，保证业务视频的需求，另外一点是像视频点播服务，一般都还提供需要部署，一个叫做原数据的管理，可以使用阿里云的表格存储的服务，将非关系型的数据支持百亿级别的表在线查询的业务。第三部分是 CDN 全网加速分发，保证用户播放流畅不卡顿。8、短视频云服务点播解决方案短视频整体架构集拍摄、剪辑、合成、上传、存储、分发等功能的一站式短视频云服务解决方案优势快速集成高度开放 API视频全链路一站式云服务性能集成:1天内自定义:可高度定制功能:主流全覆盖短视频的点播业务的场景也是集短视频的采集，导入，上传，存储，转码，管理，分发，播放于一体的，核心特点有四个：首先是快速接入成本比较经济快速，通过产品及 SDK 最快两个小时就可以结束，节省了自行开发所耗费的人力物力，让用户可以快速的接入去实现短视频的功能。第二个是接口简单，开放性强，提供的接口都是简单易用的，标准版的 SDK 可以根据业务自由的定制，对用户来说也是非常节约时间。第三个特点是功能齐备，应用广泛。在录制的功能里面提供断点录制、实时滤镜、高级美颜等功能，同时本地视频导入的时候也可以进行压缩跟裁剪，然后重点是迭代打磨，稳定可靠。视频技术经过了许多的用户比如像钉钉、梨视频、迅雷、宝宝树等等 1000 多个应用，商用上的验证是非常稳定可靠的。可以看到阿里云的视频点播服务，覆盖音视频的上传、转码、媒资管理，分发加速等各个方面的一站式音视频的解决方案，同时可以跟其他的云产品相互结合，借助灵活伸缩的海量的存储，以及 CDN 来加速分发，也可以再搭配其他的产品，帮助企业跟开发者可以快速的搭建安全，弹性高，可定制化的点播平台和应用。
-
发表了文章 2022-11-22
视频点播技术概述｜学习笔记
开发者学堂课程【场景实践 - 云端搭建直播点播系统：视频点播技术概述】学习笔记，与课程紧密联系，让用户快速学习知识。 课程地址：https://developer.aliyun.com/learning/course/513/detail/6844视频点播技术概述视频点播技术概述1、视频播放的历史变迁左上角图是春晚的直播现场，在表达视频直播在以前是一件很奢侈的事情，近年来随着互联网技术的飞速发展极大地降低了直播的门槛，使它从庙堂之高走向了普罗大众。右上角图是在直播或者点播的同时，观众可以去打弹幕，可以看出直播的手段多种多样，现在购置一些简单的设备甚至是用手机就可以开直播。下面两张图表达的是一些点播的场景，可以简单归纳一下点播的两种常用的模式，左下角图对应的是视频网站比如像优酷，这类场景的特点是少量的上传，海量的播放。右下角场景对应的是家庭监控录像或者是安防监控的点播，比如像海康威视或者银石云之类的场景是海量上传，少量点播。2、视频业务的新需求越来越多的传统业务里面都加入了视频点播随着点播门槛的逐步降低，越来越多的传统业务里都加入了视频点播的功能。从胶片中间的循环图可以看出来，随着移动互联网技术的蓬勃发展以及带宽的不断的扩增跟资费的下降，使得直播、点播越来越简单，越来越普及，而技术跟业务的发展反过来又可以推动运营手段来推陈出新，如今推出了像弹幕、打赏、送花等等新的一些运营的手段，形成了一个良性的循环。近年来随着云计算和大数据的兴起以及人工智能的飞跃，也可以看到像人脸识别、连麦互动，新的一些互动形式也陆续的出现。3、视频点播介绍视频点播 (VideoonDemand，简称 VOD) 是20世纪90年代在国外发展起来的，根据观众的要求播放节目的视频点播系统，把用户所点击或选择的视频内容，传输给所请求的用户。视频点播是计算机技术、网络技术以及多媒体技术发展的产物，是一项全新的信息服务，摆脱了传统电视时代受时空限制的束缚，解决了用户想看什么节目就看什么节目，想什么时候看就什么时候看的问题。上面的图介绍视频点播的一般过程，当用户发出点播请求的时候，流媒体服务系统也就是视频点播 vod 系统会根据用户点播的信息，将保存在片源库当中的节目信息检索出来，然后以音频跟视频的码流文件的方式通过网络传输到用户的终端，然后用户就可以播放视频。4、视频点播应用场景视频网站 更稳定、更流畅、可定制的点播服务 短视频 让短视频开发更简单 在线教育 高保障加密方案，让视频资源更安全 广电传媒高效转码、在线剪辑赋能内容生产视频点播有几个典型的应用场景，首先是视频网站是最经典的场景，为广大用户提供更稳定流畅，可自由选择定制的点播服务，然后是短视频尤其是今年非常流行的继续视频，再有在线教育、广电传媒等领域。总体来说视频点播的落地场景都需要有一些针对性的服务，比如像特效的编辑、本地转码、高速上传，然后媒资管理，分发加速等等都是有需要的。所以对于服务的提供者来说可能还面临着流量不稳定的情况，所以对计算资源的弹性伸缩有比较大的需求，所以将视频点播服务构建在云端是一种非常理想实用的选择。5、视频点播业务流程视频点播业务的一般流程，一般是用户发出点播请求然后 VOD 系统会根据点播的信息，把片库里面的对应的节目检索出来，然后音频跟视频流方式通过网络传输给用户，在终端就可以播放了，所以整个业务链条分成三个部分来看，首先是视频的采集，视频来源可能是来自直播视频的录制，也有可能是服务提供者提供的，有可能是 ugc 用户自己采集自己上传的，通过某些方式比如 APP 或者是 SDK 的方式，把视频上传到点播平台上面。第二部分是整个业务的重心，是点播服务平台，图上面列举了很多的模块和服务。第三部分是播放端，好的播放平台要提供多端播放来保证用户更好的视听体验，更高的兼容性。具体一些技术细节在各个阶段的核心诉求或者关键技术是什么，比如在采集阶段认为，用户可能会需要法律或者帧率的自适应的能力，可以根据网速的不同来自适应不同的画面质量，然后要追求用更小的流量来实现更好的播放效果，也就是对传输画质有更高的要求，点播业务一侧可能需要多路转码的能力来适应不同的区域和网络，以及可能还需要 CDN 来做加速分发，最后播放还要考虑使用软编码，根据终端的不同采用哪些协议都是要考虑的问题。6、视频点播常用技术协议RTSP/RTP/RTCP 协议簇，最早的视频传输协议（RTSP 是用来视频点播的会话控制用的 APP，主要用于数据的传输，APP 主要用于在视频流数据之外，用于丢包或者码率的控制。最早的视频传输所使用的协议需要组合使用相对比较复杂，现在已经比较少使用）HTTP 协议，主要是在互联网普及之后，主要用于 PC 端或者网页端，视频点播业务，最常见的解决方案（资源一般是用 flash 格式）HTML5，本质上和 HTTP 视频协议没有任何区别，但是播放器端不再依赖于特定的插件（HLS 协议是苹果推出的，苹果设备在近年来的普及得到广泛的应用。类似的像 adobe 推出了 HDS 以及微软推出的 NSS，以及 NPE 标准最后推出的 DSH 协议，本质上都跟 HLS 相类似，也是通过索引文件夹、视频片段的方式来实现，但是因为机构采用的技术跟实现标准不一样，所以采用的索引格式的视频片段格式都不太一样。H5 本身跟 HTTP 视频协议没有区别，只是因为它符合 H5 的规范，使播放器一端不再依赖于特定的插件，采用 HTML 当中去嵌入 video 标签，同时去指明视频播放地址 url 就可以播放，非常方便。）RTMP，是 adobe 公司推出的视频协议。需要专用的服务器，如 FMS 等。（RTMP主要的特点是高效，在国内稍有规模的直播类 APP 基本都是采用 RTMP 协议，主要是因为低延迟性以及高稳定性，非常适合直播业务)7、视频点播技术的挑战资源消耗大且增长迅速用户观看体验在海量并发业务下难以保障重资产业务，IT 成本巨大违法违规内容控制十分棘手内容是核心价值，必须有能够有力保护视频内容，防止盗链视频点播技术面临的挑战首先是存储问题，资源消耗比较大并且增长迅速，因为业务不同于外的业务，对存储资源的消耗十分巨大，一个成规模的视频点播的站点通常会有数百 TB，甚至是 PB 级别的存储需求，普通的 IDC 或者是规模比较小的云服务商的基础设施比较有限，很容易成为云点播业务增长爆发阶段的瓶颈。到那个时候扩充的难度就比较大，经营成本就会很高。同时对于网络带宽跟网络的质量也是比较敏感的，因为高清流畅是视频点播最重要的用户体验，高清视频的码率比较高，需要有充足优质的网络带宽来保证首播延迟，在用户容忍的范围之内，然后保证视频可以在大并发的场景下还能流畅地观看都是很重要的问题。同时还要兼顾视频分发带来的高带宽的成本问题，都是要去考虑，对于视频点播平台提供商来说，有一个非常重要的工作是对平台上的视频内容进行鉴黄、鉴恐的工作，如果靠人力来完成成本高昂并且效率低下，是非常重要的问题。另外一点由于内容是核心价值，所以必须要足够的能力来保护视频的内容，防止被盗取被盗链。针对这些问题阿里云推出视频点播的一整套解决方案，为用户提供便利快捷并且稳定高效的视频点播服务。
-
发表了文章 2022-11-22
阿里云 CDN 服务架构及应用场景｜学习笔记
开发者学堂课程【通过 CDN 为网站提速：阿里云 CDN 服务架构及应用场景】学习笔记，与课程紧密联系，让用户快速学习知识。 课程地址：https://developer.aliyun.com/learning/course/511/detail/6833阿里云 CDN 服务架构及应用场景 目录一、CDN 服务架构二、网络站点应用加速三、视音频点播/大文件下载分发加速四、视频直播加速五、移动应用加速 一、CDN 服务架构阿里云基础架构分为三层，主站发布环境、骨干中转环境、用户响应环境。主站发布环境包括阿里主站 DNS 系统、应用发布集群、内容存储集群，三部分组成主站发布环境。骨干中转环境包括 CDN 调度系统、L2cache集群。L2cache层节点位于用户源站和 CDNL1 节点中间的缓存服务器可以缓存 CDNL1 节点的回源访问，通过在全网架设多个 BGP 中转节点，能够有效降低用户源站的访问压力。CDN 智能调度系统能够动态分配缓存节点的资源，对 CDN 的缓存节点进行健康检查。用户响应环境包括用户接入本地 DNS 服务器和 L1cache 集群L1节点遍布于各地域各运营商的 CDN 边缘服务器，通过对源站资源的回源拉取和缓存，为用户提供毫秒级的访问延迟体验。 二、网络站点应用加速CDN 能实现对站点或应用中大量静态资源的加速分发，用户使用之前建议对站点内容进行动静分离。动态文件和静态文件放置不同的域名，动态文件请求可以使用 ECS 服务器进行响应，静态资源使用 OSS 云存储服务，阿里云 CDN 无缝与阿里云 OSS 进行衔接，实现对静态资源的加速分发。三、视音频点播/大文件下载分发加速客户端将视频文件上传请求发送到负载均衡服务器后端的 ECS 服务器集群，ECS 应用将视频文件保存到 OSS 存储中，可以使用媒体转码服务进行视、音频的转码，然后将转码后的视、音频文件推送到CDN 加速节点进行缓存，用户可就近访问 CDN 的资源进行视、音频点播和大文件的下载。架构能提升 CDN 的回源速度，节约回源带宽成本。 四、视频直播加速通过大规模的分布式实时转码技术搭配 CDN 打造视频的直播平台，此架构的优势，第一接入便捷，不管用户是在个人 PC 电脑或者是 APP 端都可以直接进行视频的采集上传。终端用户可以从各个运营商，各个地点接入到直播平台来浏览视频，通过 CDN 毫秒级别的急速享用优势和全网范围内的分布式缓存架构，能够提供低延迟，高并发的流畅视频直播服务。 五、移动应用加速移动应用加速是阿里云针对移动应用推出的动静态全网加速产品，依托阿里云遍布全球的 CDN 节点和海量的带宽资源等基础设施，使用智能域名解析，无线协议优化，内容动态压缩等技术。为开发者提供更快更稳定的网络接入能力，能够分发移动端内的图片、页面、视频等内容，缩短访问时间，有效提升移动应用的可用性和用户体验。
-
发表了文章 2022-11-22
结构化数据迁移介绍｜学习笔记
开发者学堂课程【上云迁移实战：结构化数据迁移介绍】学习笔记，与课程紧密联系，让用户快速学习知识。 课程地址：https://developer.aliyun.com/learning/course/514/detail/6855结构化数据迁移介绍结构化数据1、什么是结构化数据结构化数据即行数据，可以用二维表结构来逻辑表达实现的数据，一般都是存储在关系型数据库中通过 sql 语句进行管理。2、常见结构化数据库常见的结构化数据库有 MySQL、 SQL server、 ORACLE 等。MySQL 是关系型数据库管理系统，由瑞典 MySQL ab 公司开发，目前属于 ORACLE 旗下， MySQL 是最流行的关系型数据库管理系统之一。 SQL server 是微软公司推出的关系型数据库管理系统。具有使用方便、可伸缩性好、与相关软件集成度比较高的优点。ORACLE 是甲骨文公司的一款关系型数据库管理系统，是数据库领域一直处于领先地位的产品，系统可移植信号，使用方便，功能强，适用于各类大中小危机环境，是一种高效率、可靠性好的适应高吞吐量的数据库解决方案。3、结构化数据迁移场景ECS 上的自建数据库迁移至阿里云 RDS本地 IDC 服务器上的数据库迁移至阿里云 RDS本地 IDC 服务器上的数据库迁移至阿里云 ECS 自建数据库4、结构化数据迁移工具Mysql 可以使用阿里云工具数据传输服 DTS 来进行数据迁移SQL Server 可以通过 DTS 和 SSMS 工具进行迁移Oracle 可以通过 DTS RMAN 工具进行迁移5、什么是 DTS数据传输( DataTransmission )服务 DTS 是阿里云提供的一种支持 RDBMS (关系型数据库)、NoSQL、OLAP 等多种数据源之间数据交互的数据流服务。能够快速的将本地数据库或者 RDS 中的实例迁移到另一个 RDS 中。6、数据传输服务 DTS：三种迁移模式结构迁移支持结构迁移对象有表、视图、触发器、存储过程、存储函数全量数据迁移无主键的非事务表会被锁定无法写入，时长依赖于这些表的数据量大小，在这些无主键非事务表迁移完成后，锁才会释放增量数据迁移迁移过程中，如果数据结构发生变化，变化的数据结构无法迁移到目标实例7、数据传输服务 DTS：迁移模式支持列表Oracle 向 RDS MySQL 版本迁移时不支持增量迁移 MySQL 向 PetaData 迁移时不支持结构迁移和增量迁移 8、数据传输服务 DTS：产品优势丰富多样高性能安全可靠简单易用丰富多样数据传输服务能够支持多种同异构数据源之间的迁移同步，例如 Oracle 迁移到 mysql 、Oracle 迁移到 PPS，对于异构数据源之间的迁移，数据传输服务支持结构对象定义的转化，例如将 Oracle 中的同义词转换为对应的同义词定义。数据传输服务支持多种传输方式数据迁移、实时数据订阅及数据实时同步，其中实时数据订阅及数据实时同步均为实时数据传输方式。数据实时同步支持两个数据源之间的单向及双向同步，可实现数据异地灾备、异地多活应用、就近访问查询报表分流实时数据仓库等应用场景。为降低数据迁移对应用的影响，数据迁移功能支持不停服迁移方式，不停服迁移，可实现在数据迁移过程中应用停机时间降低到分钟级别，高性能数据传输服务，使用高规格的服务器来保证每条迁移同步联络，都拥有良好的传输性能。对于数据迁移、数据传输服务，底层使用了多种性能优化措施全量数据迁移，高峰时期性能可达到70兆每秒20万 PPS。相对于传统的数据同步工具，数据传输服务的实时同步功能，能够将并发力度缩小到事务级别。能够并发同步同张表的更新数据从而极大提升同步性能，高峰时期同步性能可达到三万万每秒。安全可靠数据传输服务底层为服务集群，集群内任何一个节点宕机或发生故障，控制中心都能够将节点上的所有任务秒级切换到其他节点上，列入稳定性高达99.95%。数据传输服务内部对部分传输链路提供七成24小时的数据准确性调研，快速发现并纠正传输数据保证传输数据的可靠性。数据传输服务各模块间采用安全传输协议及安全 token 认证有效保证数据传输可靠性。简单易用数据传输服务，提供可视化管理界面，提供向导式链路创建流程，用户可以在其控制台简单轻松的创建自己的传输链路，数据传输服务控制台展示了链路的传输状态以及进度传输性能的信息，用户可以方便管理自己的传输链路。为了解决网络或系统异常等导致链路中断的问题，数据传输服务提供电路断点市场的功能，且定期监测所有链路的状态，一旦发现链路异常先尝试自动修复重启。如果链路需要用户介入修复，那么用户可以直接在控制台修复后触发电路重启。9、数据传输服务 DTS：应用场景零停机上云迁移：数据迁移支持的增量迁移功能可以实现在上云迁移过程中，本地业务继续提供服务，从而最大程度降低数据迁移期间应用停服时间（如果要将本地数据库迁移到阿里云上，可以使用数据库传输提供的数据迁移功能。数据迁移功能可以轻松实现数据一键上云，在数据传输控制台通过几个简单的步骤即可开始数据上云迁移）异地灾备：实时同步功能可以实现不同地区的两个 RDS 实例间的增量数据实时同步，包括 DDL、DML. 同步的两个 RDS 实例构成了主从架构（要提高数据安全性需要构建 IPS，异地灾备时可以使用数据传输提供的实时同步功能）异地多活（单元化）：各个业务单元可以分布在不同的地域，从而有效解决了单地域部署带来的基础设施的扩展限制、服务可持续性及远距离访问体验问题（单元化异地多活，随着业务的快速发展对于很多公，构建异地地域的技术体系架构会面临诸如下面的多种问题，基础设施的有限性限制了业务的可扩展性，城市级别的故障、灾害影响服务的可持续性，远距离用户访问延迟高严重影响用户体验。为解决企业遇到的这些问题，用户可以选择构建异地多活架构，在同城异地构建多个单元，根据业务的某个维度，将业务流量切分到某个单元，各个业务单元可以分布在不同的地域）降低跨地区访问延迟：使用数据传输服务提供的数据实时同步功能，选择业务量大的地区部署数据库主库承担业务写流量，在有业务访问的其他地区均构建主实例的业务读库，所有地区的全部路由到业务总库，各地区的读业务路由到本地区的业务区，从而有效降低跨地域访问数据库导致的高延迟问题，极大提升用户体验。（降低跨地域访问延迟，如果存在跨地区的业务访问为解决跨地区访问数据库带来的高延迟问题。）本地灾备：通过 DTS 可实现本地自建数据库跟 RDS 实例之间的数据实时同步，轻松构建本地灾备中心。当 RDS 出现异常时，可快速将业务切换到本地灾备中心，秒级恢复服务，保证服务的可持续性（本地灾备提高数据库安全性需要在构建 RDS 的本地灾备时可以使用数据传输服务，DTS 提供的和云数据同步功能）消息转发：通过数据订阅提供的消费SDK订阅RDS增量数据然后触发更新业务（消息转发如果需要实现获取数据库变更数据出发业务）
-
发表了文章 2022-11-22
性能测试 PTS 销售指南| 学习笔记
开发者学堂课程【云原生中间件产品销售红宝书：性能测试 PTS 销售指南】学习笔记，与课程紧密联系，让用户快速学习知识。课程地址：https://developer.aliyun.com/learning/course/629/detail/9888性能测试 PTS 销售指南内容介绍：一、双11来临，如何保障业务系统稳定性?二、PTS 产品简介 一、双11来临，如何保障业务系统稳定性?1、大促像阿里巴巴，做双十一大促已经是第十一年，从刚开始会经过很痛苦的血泪史，比如刚开始会胸有成竹的准备一场活动，像秒杀或者抢购之类的活动，会带来多少营收，用户量会增加多少，但是在运行时往往会发现，比较多的情况是会提示活动太火爆，过一会再来试试，甚至整个页面都打不开，本来是准备一场希望用户能够赞美的产品或者玩的很嗨的一次活动到，最后会迎来比较多的投诉。2、事例，参加秒杀活动最后无法付款，举报是因为做虚假活动，账号有问题，还要求赔付金额，从过程上来看大促期间悲痛的历史都是因为应对的准备不足，刚开始把整个过程都想的理想化，最终的结果造成经济上的损失，前期的运营投入已经做很多，但是后面并没有完美的运营的效果，品牌的形象会受到损失，被认为品牌的形象都是骗人，秒杀活动也是骗人的，直接的结果造成客户的流失甚至是有客户的投诉。3、因为不好的过程或者血泪史总结为什么大促会失败？大促失败原因：（1）缺乏意识只知道准备资源，不知道要准确的准备资源，没有压测的意识。（2）没有按照流程准备简单的进行了单次测试，没有系统化的准备、操作、优化、验证。登陆，查看，提交订单，与支付宝支付的环节。（3）用错工具自己使用了开源的工具，不能模拟真实的流量来源进行压测。秒杀会有损失的峰值，类似于淘宝双11时峰值就是在前两分钟，一瞬间用户量就会非常的大，希望模拟出真实的流量进行一次压测，和实际场景匹配。（4）不知道如何定位优化没有详细的报告，不知道瓶颈点在哪里，没来得及优化。有了意识，按照流程操作，选对的工具，最后也发现希望有一百万人来访问，只有五十万，不知道原因是什么，没有进行优化是因为没有详细的报告或者没有统计的数据，面对压测结果的场景很茫然，所以基本上大促失败会由这些原因组成。4、为什么要做性能测试从技术和品牌或者运营产品的角度一共分成四部分。（1）品牌由于对大流量的准备不足,导致给企业带来直接经济损失或者品牌形象受损的事情经常发生。在产品上市时品牌形象就是打入市场最重要的指标，客户对品牌的第一印象是非常重要的，很难的争取到市场的预算，运营的预算，做一次大的活动，在活动一开场时就崩盘会导致的品牌形象大大的受损。（2）体验产品核心功能的体验,特别是日常峰值下的性能表现尤为重要。大量数据表明,每0.1秒的核心体验响应时间延长会导致1%的营收下降。用户体验包含两部分，第一部分是日常的用户体验，第二部分是大促活动的用户体验，类似于在打开网站时首频超过一秒都不能渲染完成，大多数人不会再打开网站，网站的首页三秒之内不能渲染完成，用户90%就不会再来这里，所以用户体验也非常重要。（3）成本不同业务模型下容量配比不同,如何基于精准的流量模拟来完成最低成本的容量预估。成本包括人力成本和实际能够承受容量的资金的成本，所以做容量评估或者性能准备时需要最低的人力成本或者最低的资源成本完成。（4）不确定性分布式系统复杂度和业务发展的不确定性,导致需要经常性检查系统的瓶颈点。技术或者业务上的不确定性，现在的系统都是分布式的系统，各种上云或者弹性计算或者混合云，分布式系统的复杂度是非常高的，再加上移动互联网时代，业务发展具有不确定性，比如爆款的活动，子弹短信就是新型的业务，会有突增的不确定性，所以需要经常性的检查系统的瓶颈点在哪里，通过性能测试方式检查哪里有问题，需要如何做。5、理想大促-活动准备环节以前做大促时类似滑锁过河，特别的刺激，就是惊险的度过，但是里面的隐患是非常大的，像滑锁一样没有安全感，期望的状态就像港珠澳大桥一样能够顺滑安全非常通畅的度过一次大促。所以在准备大促时理想的大促活动准备环节是，对业务架构或者技术架构进行梳理，比如方在做淘宝大促时涉及到的业务点是什么，业务点涉及到的技术点是什么，都需要进行梳理。第二步梳理完业务之后就要开始做压测的准备，分为环境的准备和数据的准备。第三步准备好数据，梳理好业务之后，真正的开始做压测，平静点的检查，容量的验证甚至是预案的验证。第五步需要根据的压测结果定位的平均点，发现问题做容量的微调或者预值的更新或者配置的更新，甚至是简单的扩容，再次验证，最后在活动时需要正常的活动保障，以及在活动结束之后的总结。所以理想的大促环节应该是有序的，理想状态下有序的完好的进行，才能对大促有好的准备过程。6、客户案例介绍-某X利(全球直销品牌)它是经典电商大促的场景，它要在中秋和国庆时做一次电商的大促，8月份时已经做过一次大促，按照传统的有惊有险的方式准备，大促之后发现电商营销失败，很多用户网站打不开，要买的东西买不到，所以他们开始考虑要做性能测试，第一个看重的是来阿里云寻找产品，他们的业务场景经典的，就是官网的电商大促包括秒杀，登录支付，提交订单场景，项目的背景在8月份，中秋是9月份，中间的时间非常少，所以面临着时间很紧迫，系统又很复杂，整个任务会很繁重，因为他们之前有一次失败的经验所以不能再失败，再失败对后面产生影响，用户看中性能测试服务之后开始做事情，对用户最终的收益就是秒杀业务，能够真正提前验证好完成，特殊的是它们对地域或者运营商的来源，客户会有群体的效应，大一点的业务或者业务场景都会有诉求，比如有一部分用户是来自杭州，有一部分用户是来自广东，还有一部分来自移动，有一部分来自联通，会有地域的诉求，他们的业务场景里面，最后它们完整的度过大促，整个业务的营收或者平台的口碑都是非常好的，公司老板很重视。提升产品的口碑，也在压测的过程中会建议给用户使用其他的阿里云的产品，比如像hahs的限流降级以及dts或者引入咨询服务，因为在时间紧迫时会需要投入咨询人力，操作的方法是在刚开始时进行业务的梳理，根据涉及到的核心业务构造对应的数据，比如登录的用户数据，来源数据，电商里面涉及到的产品分类，产品的数据，实施一轮压测完成之后开始根据出的报告做一次问题的定位并且做优化的改造，再做一轮的验证，在中间的过程中引入新的产品，比如熔断保护，因为在整个压测到后期时，项目背景时间紧，到后期时来不及优化或者无法彻底解决时可以通过熔断保护，保护自己的底层业务，不至于整个系统都会挂掉，还进行dts的引入，多地域部署，实现多活架构做保障。（1）客户场景客户类型：中秋、国庆电商大促。业务场景：8月首次大促,准备不足,线上电商营销失败,中秋大促压力较大、官网电商大促,含秒杀，支付等场景。项目背景：时间紧迫、系统复杂、任务繁重。（2）价值客户收益：真实的模拟秒杀业务、多地域/运营商来源大流量，高真实度的完成性能测试,顺利完成大促，业务营收、平台口碑。我们的收益：提升产品口碑,现在活动前都会使用压测产品，从PTS带入更多产品使用( AHAS. DTS咨询服务)，现是AHAS的重点标杆客户。（3）操作方法压测入场：梳理核心业务、 构造数据、压测实施，问题定位、 优化改造、再次验证。新产品引入：熔断保护: 保证大部分用户的实时体验;大促目标数据确认：限流保护( AHAS )，DTS 引入，多活架构做保障。（4）为何能成功?业务梳理清晰，选择了主流、可靠的压测工具，性能测试服务。7、大促成功原因（1）清晰的业务与数据梳理清楚压测范围，比如淘宝双11时为电商系列会涉及到，像有其他业务的不太跟电商类有关系的就不会涉及，准备好相应的数据，登录的用户数据，商品数据。（2）最正确的工具模拟真实的流量来源，模拟真实业务场景，比如的秒杀场景能够损时高并发的访问，操作简便，繁琐的工具会使用户使用心理上排斥，其次操作也会复杂，增加的整个流程的成本，问题定位(全方位的监控)，甚至给出合理的建议，当前系统能够平稳的运行，多大的流量，结论性，产出细致的报告，在线下分析问题点在哪里。（3)成功的大促准备准确的预估容量,安全可靠的系统稳定性准备.8、压测方法对比（1）业界常见压测方式开源工具：灵活、再塑性强、协议支持广、自定义方法、并发能力低、代码能力要求高。开源工具的优势是很灵活，再塑性强，有jar包就能够实现所有的协议的支持，可以自定义方法，灵活的劣势就是并发能力不高，同时代码要求能力会非常高，它有版本的概念，官网发布新版本之后，本地的版本需要跟着迭代的，同时如果想要做高并发就需要自己在上面搭一套控制层，成本就会非常高。自研平台：高成本、协议适配、人力/资源成本、代码侵入、维护成本高、稳定性较弱。自研平台基于开源工具做的事情，除了成本高之外还有代码侵入的风险，需要有专门的团队，至少要有专门的人力维持，稳定性差，所以自研平台不推荐。竞品工具：价格高、售后支持力度不够、操作复杂、流量无法定制。在国内甚至是国外时会有其他做性能测试的平台，跟竞品相比，竞品上面出现价格高的问题，售后的支持力度不够，页面操作的复杂度高，流量无法定制。（2）PTS性能压测服务基于与开源工具资源平台或者竞品的对比，pts的性能压测服务的优点是高并发的能力，阿里巴巴自己在做淘宝双11压测，用的压测服务是完全一模一样的，由内部做的压测的平台对外商业化的输出，所以底层完全一样，理解成淘宝双11用什么做压测，外面的客户也可以用什么做压测，工具一样。高并发能力，目前用到最大高并发的用户已经达到一百万的并发，对应的rps有八百万。真实流量(支持定制化流量)有从cdn的流量同时还可以定制化流量，比如整个100%的流量其中有50%自于广东的移动，20%自于杭州电信，支持定制化。全方位定位能力，压测之后的报告日志定位。JMeter的支持，对使用开源工具用的多的同学，支持开源，很多做性能测试的同学，对开源的工具非常熟悉，他不想再切到你的平台，他想要沿用原来的一套，但是又想要高并发真实的能力以及定位的能力，所以可以通过pds直接用，JMeter类型的压测即可。请求采样日志/错误日志，无论是竞品还是开源工具都没有。VPC网络压测，有主题系列文章讲阿里巴巴是如何做准备双11，可以在公众号上查看，在做全链路压测之前有部分业务想要自己做单链路的压测，在内部的压测，比如rpc、mqtt、double都是需要在vpc网络内部进行，pts的压测也支持vpc网络配置，和公网一模一样，只要切换网络来源即可。自动得出系统能力结论，在容量评估的模式下会自动压测得出结论，当前的业务系统最佳能够跑的压力能力是多少，最佳是指基本上不会报错，rt会非常正常，正常是由业务决定的，只要告诉R T不能超过100毫秒，错误率不得低于90%，会自动压测得出最佳的压力点是多少，就是系统下跑这么多能量，压力不会出任何问题，会告诉当前能够容忍小级别的错误，也就是限流的阈值是多少，最后会告诉压力达到破坏点，系统会出现问题，所以初次做性能压测或者无法判断系统是多少时非常有帮助。 二、PTS 产品简介可以模拟各种客户端，各种浏览器，各种移动端，从全世界各地发起流量，压测对象可以是公有云，专有云，自建idc以及vpc网络就是阿里云上面的内部网络。1、非阿里云客户能用吗?可以,无论客户是公有云/专有云/混合云/自建IDC,无论什么云厂商只要在公网可访问就能通过PTS来压测。阿里云上的客户有另外的好处就是可以做vpc网络的压测。2、使用上需要什么门槛吗?不需要专业测试背景,只需要懂一点http协议即可进行压测场景的设置。甚至业务请求可以通过云端录制器来录制抓取。pts是纯saas工具，开箱即用就是打开页面在页面上配置甚至通过的云端录制器都不需要知道的登录接口详细的名字是什么，详细的参数是什么，提交订单的时候，订单名字是大写还是小写都没关系，可以通过云端录制的模式帮快速的录到接口，只要后期更改要压测的数据即可。3、压测之后的问题定位 部署在阿里云不在阿里云发起侧(客户端)指标请求、响应时间、错误率等多维度统计PTS自带总结本次压测系统能力PTS自带基础性能容器、ECS、RDS、SLB的CPU、负载、网络、磁盘等基础指标云监控后续提供客户端部署采集应用级别性能针对应用级别的链路分析、性能定位ARMS业务实时监控 ARMS业务实时监控pts提供丰富的报告，针对于阿里云和非阿里云用户稍微有一点不一样，监控是分层的，会有客户端的监控，客户端的监控就是用户层面的监控，基础性能就是系统的基础负载能力，能够看到应用级别的监控，客户级别的监控就是常见的请求数，成功率，响应时间是多少，pts自带，无论是不是在阿里云上都会有能力，总结本次压测系统能力，在某个压测模式下会告诉当前系统能够承载的最佳压力值，限流的阈值是多少，以及达到多少量级时系统有问题，基础性能包括基础负载，像cpu或者网络或者内存利用率，slb的带宽连接数，使用率，在阿里云上的用户都可以看到云监控的数据，会直接拿云监控的数据看，不在阿里云上的用户会提供客户端部署采集，同时会上线功能根据阿里云的用户把整个部署的结构，比如有哪些ecs挂载在哪些slb下面，它们的性能情况是什么样子，压测出现问题是具体哪个ecs或者slb有问题，功能预计11月中旬会上线。有客户端的监控，有底层的监控，中间就是应用级别的监控，客户端有rt有异常，负载高，具体是因为什么引起，需要看业务的问题定位，已经集成arms的业务实施监控，可以做链路的分析和性能的定位所以pds上面的压测是提供了比较全面的端到端的监控以及总结性的东西。4、典型使用压测的业务场景（1）新系统上线新系统上线,准确探知站点能力,防止一上线就被用户流量打垮。（2）峰值业务稳定性类似阿里双11的峰值业务稳定性考验，保障峰值业务不受损。（3）站点容量规划搬站成本优化,对站点进行精细化的容量规划。（4）性能瓶颈探测探测站点的性能瓶颈,提升站点的整体服务能力和吞吐量。5、产品主要客户类型PTS的30%压测流量中去向非阿里云,业务触及大量友商、IDC。平安，安利等。6、PTS客户场景类型客户类型场景类型实际案例阿里云上重要客户重大活动窗口保障类世界杯、双11、跨年和春节,摸顶峰值流量的系统负载和系统性能;搬站上云类如屈臣氏、小天才,搬站前新系统的验证及容量准备;或者ecs容器专有云头部类个人所得税、广发银行,通过PTS全链路压测解决方案完成多轮全链路压测;公有云头部类如趣头条、联合利华、茅台、如新、完美等,都采用PTS作为外网进行官网上新、大促活动等压测;现象级类如子弹短信、喜茶、毒APP等,新型业务模式,突发性业务快速增长;海外业务进驻类booking在阿里云.上的业务基于PTS进行压测验收;非云上重要客户友商头部( Ucloud )头部客户懂球帝,世界杯的大促准备，压测后有10倍业务性能提升;没有选择用自己的产品而是选择pts，钩子/潜在上云如华南区最大潜客安利，现已通过压测引入了更多产品;SAAS化输出重要的运营商,还有交行、平安、星巴克等知名客户通过PTS的SaaS形态享受产品和服务;行业/场景云钉钉云和钉钉云有机联动，支持50+钉钉重要三方应用的可信压测,确保钉钉生态应用的稳定性;阿里零售云零售云基于PTS封装其订单场景的定制化压测; 7、PTS客户行业类型客户类型客户举例使用方式和压测内容金融类交行验证自己的APP.上活动能力,验证登录、秒杀、积分兑换等活动;保险类太平验证开门红活动,新服务上线前能力验证等,涉及登录、保单生成、提交保单、思考等待及条件选择;业务复杂度高互联网电商天猫双11验证登录、秒杀、订单支付等涉及三方系统的验证;社区电商格家、思埠新型社区类电商,除电商经典流程之外,还涉及线上线下系统调用,微商城等压测;新网红业务子弹短信、喜茶验证IM类型压测、爆款/直播类型压测;传统通信中移IT系统的人员压测,因访问人次较多、数据查询复杂,进行IT组织架构的系统压测;新零售外卖系统线上与线下收银系统对接,线上多端流量入口的严格配比压测(如小程序、APP、第三方点餐系统)在线教育某培训中心答题环节的思考等待时间需考虑到压测方案中,高并发/长时间持续的施压。政企类服务个税、学习强国流量配比定制化高,如地域/运营流量配置、人员集中度、与其他三方系统联动度高,数据真实性。 8、客户案例介绍-太平（1）客户场景业务场景：开门红活动、新产品发布(太平宝宝)。项目背景：影响品牌和业务体验、业务接口复杂、业务数据安全性第一。（2）价值客户收益：托管式压测服务 (专家服务) , 投入少、活动和产品发布顺利进行，帮它用pds进行压测给出相应的优化建议。我们的收益：大场景客户对产品的验收能力、 产品信任度高，从PTS带入更多产品使用( AHAS、每年扩容服务)，专家服务的收费形式，每年都持续使用PTS进行压测。（3）打法策略压测入场：梳理核心业务、构造数据、压测实时，问题定位、优化改造、再次验证新产品引入：熔断保护:保证大部分用户的实时体验;大促目标数据确认:限流保护( AHAS )，按照终态压测结果+预留buffer形式，进行扩容。9、PTS客户场景销售切入点（1）迁移上云：上云迁移，需要检测新系统性能。（2）新业务上线：如电商系统，秒杀模块新上线新上。（3）验收项目：作为第三方测试下交付系统是否验收达标。（4）成本控制：通过压测检查到短板，把相应富裕的资源释放或者补给短板想节省机器成本。（5）扩容：扩容后需要检验下资源时候达到预期，是否浪费成本。（6）开源方案替代：JMeter或者破解版LoadRunner。（7）友商竞品：云智慧/OneAPM/腾讯压测，PTS更有价格优势，且简单易用流量更广。10、PTS的计费方式（1）PTS采用预付费购买资源包的形式收费。解决方案需另外按照人天计算。（2）计费单位是VUM。VUM=VU (压测任务中并发用户数) *M (压测场景执行时长,按分钟粒度,不满一分钟按一分钟计算) ,举例: 4并发用户运行2分钟即8VUM，8并发用户运行1分钟也是8VUM。举例，对应成移动的加油包，假设买个vum是一百万的资源包，它类似于移动是40G的流量包，资源包会有能力的上限vu就是能模拟多少个并发用户，最大的带宽是100兆，剩下的就是时间，100兆跑二十分钟，相当于是两个g再乘以60就会有时间的概念，vum是能力上限乘以运行的时间，能力乘以运行的时间就是这次要扣掉的量，8vum可以是四个并发用户跑两分钟或者八个并发用户跑一分钟，单位一样。
-
发表了文章 2022-11-21
Agent 的使用-Spring Boot | 学习笔记
开发者学堂课程【分布式链路追踪 Skywalking：Agent 的使用-Spring Boot】学习笔记，与课程紧密连接，让用户快速学习知识。课程地址：https://developer.aliyun.com/learning/course/743/detail/13157Agent 的使用-Spring Boot内容介绍：一、Window 下 Tomcat7和8中使用 Agent二、Spring Boot 中使用 Agent一、Window 下 Tomcat7和8中使用 Agent在 window 中使用 Agent 和在 Linux 下使用的方式类似，但是需要修改的文件从原来的 catalina.sh 变成了 catalina.bat，因为 bat 是在 window下 使用的，所以需要将第一行修改为 bat 能识别的一串代码：set "CATALINA_OPTS=-javaagent:/path/to/skywalking-agent/skywalking-agent.jar"，在 set "CATALINA_OPTS 后加上 javaagent 的使用方式，用 -javaagent 指向 javaagent 的目录以及它的架包。也就是说，skywalking 在 window 下的使用和在 Linux 下使用的方式其实是一样的。，只不过在语法方面需要修改为 bat。二、Spring Boot 中使用 Agent1. Skywalking 与Spring Boot 集成下面学习 Skywalking 如何与Spring Boot 做集成，来监控 Spring Boot 中接口的调用（1）处理工作如图：现在处于一个 agent 的目录下，而这个目录当前实际上是被 Tomcat 使用的。将 agent 拷贝一份，如图：将其改为 agent_boot，然后进入 agent_boot 这个目录下。这里需要修改的依旧是 config 目录，如图：进入 config 目录，找到配置文件进行修改，如图：将 agent.service_name 这句话的服务名改为 skywalking_boot，这样用于做一个服务的区别，即可以分出到底是 Tomcat 发布还是 spring_boot 发布的。此时，在 agentboot 下已经修改完配置文件，也就是说现在有两个 agent 可以使用，一个是 Tomcat 进行使用的，一个是 spring_boot 使用的。这样的方式看似很麻烦，但是设想如果将来应用上线，一般情况下一个虚拟仪只会放一个应用，为了避免过多的应用产生资源的争抢，这个时候就可以在虚拟仪上只放置一份 agent 。不过如果只是演示，就需要在一台虚拟机上启用多个应用，因此会认为这种方式麻烦。这个问题也可以用插件的方式解决。（2）上传应用将 skywalking_springboot 应用上传到虚拟机中，同时启动。以下是 springboot 的一部分代码：<parent><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-parent</artifactId><version>2.1.10.RELEASE</version><relativePath/>＜!--Lookup parent from repository--＞</parent><groupId>com.itcast</groupId><artifactId>skywalking_springboot<artifactId><dependencies><dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-web</artifactId>在 pom 中，已经引入了 springboot 相关的依赖，这个依赖使用的版本号是2.1.10 ，而且使用了 spring-boot-starer-web 进行 springmvc 的一个集成。还提供了一个 controller，如以下代码：RestControllerpublic class MyController｛//正常访问接口@RequestMapping("/sayBoot")public String sayBoot() {return "Hello Boot!"; ｝//异常访问接口@RequestMapping("/exception")public String exception(){int i =1/0;return "Hello Boot!";这个 controller 有两个接口，一个叫 sayboot，它是一个正常访问的接口；一个叫 exception，是一个异常访问的接口，这个接口是通过1/0的方式来抛出一个除0异常。如图，把 springboot 工程上传到虚拟机中：使用工具进行上传，上传后即可通过启动 springboot 来进行验证。（3）启动 Springboot在启动前需要注意，正常启动前的应用不会和 skywalking 做集成，所以需要通过启动命令中添加探针的方式来进行启动，这个方式和之前使用 Tomcat 的方式是类似的如下代码：java -javaagentl/usr/local/skywalking/apache-skywalking-apm-bin/agent_boot/skywalking-agent.jar -Dserver.port=8082 -jarskywalking_springboot.jar &在命令中加上 -javaagent 参数来指定 javaagent 的一个位置。如图：进行启动，首先把目录切换到 usr/local/skywalking 下，如图：可以看到，Springboot 已经上传成功。在这个目录下，可以通过 java 加上参数 javaagent 来启动，此时如果拷贝错误，需要手动输入，然后找到 skywalking.jar ，在加上参数之后指定启动的端口，也就是 Dserver.port=8082，然后再通过 /jar 命令找到架包并且用&进行后端的启动。此时虽然在控制端还是打出了启动执行命令，但是它并不是在前端进行启动而是通过后台进行启动，所以即便把控制台进行退出也不会影响到系统运行。此时，应用启动成功。（4）访问如图：在浏览器进行应用的访问。将端口改为8082，应用名不需要加，然后看到它的一个接口 sayboot，来进行验证。如果返回了 helloboot，就说明是一个正常访问。然后再访问后面的异常接口，如图：如图，这里前端报错，报的是/ by zero，也就是除0错误，抛出一个除0异常同时标记成500，这说明这是一个异常访问。（5）查看 skywalking 信息在 skywalking 中查看是否有上述记录，如图：如图，这里有两条访问记录，在 skywalking_boot 下的依次是 exception 和 sayboot这两个接口。然后在追踪中详细查看信息，如图，exception 已经标红，证明它是一次失败的调用，它的持续时间是359毫秒。而 sayboot 是一次正常的调用，所以是蓝色的，持续时间是296毫秒。在服务上找到 springboot 的服务，同时它的实例在141上，进程 ID 是10986，证明这个应用和这个实例已经被我们监控起来了。如图，查看拓扑图：可以看到，现在 User 一方面调用了skywalking_boot，一方面又调用了 sky walking_tomcat，而这两个本质上都是 springmvc 的项目，springboot 实际上是通过 web 端进行访问，也是基于 mvc 。至此，springboot 已经和 skywalking 完成了集成。其实启动的方式大致相同，只是 springboot 的启动需要在 java 后 加上 javaagent 这个参数来指定一个 agent 探针。
-
发表了文章 2022-11-21
APM 系统概述 | 学习笔记
开发者学堂课程【分布式链路追踪 Skywalking：APM 系统概述】学习笔记，与课程紧密连接，让用户快速学习知识。课程地址：https://developer.aliyun.com/learning/course/743/detail/13151APM 系统概述什么是 APM 系统由于 Skywalking 本质上是一个 APM 系统，因此了解 APM 系统能够更好理解 Skywalking。1.APM 系统概述（1）APM(Application Performance Management) 即应用性能管理系统，是对企业系统即时监控以实现对应用程序性能管理和故障管理的系统化的解决方案。应用性能管理，主要指对企业的关键业务应用进行监测、优化，提高企业应用的可靠性和质量，保证用户得到良好的服务，降低总拥有成本。APM 系统是可以帮助理解系统行为、用于分析性能问题的工具，以便发生故障的时候，能够快速定位和解决问题。解析：APM 的英文全称是 Application Performance Management，即应用性能管理系统。主要是为了聚焦线上应用程序的一个性能指标，通过性能指标可以解决线上出现的问题，当故障发生时，通过 APM 系统能够快速定位到问题产生的位置，达到快速解决问题的效果。系统不只保障了它的高可靠性和应用的质量，同时保障了用户可以得到更好的服务，还可以降低 APM 的成本。2.分布式链路追踪随着分布式系统和微服务架构的出现，一次用户的请求会经过多个系统，不同服务之间的调用关系十分复杂，任何一个系统出错都可能影响整个请求的处理结果。以往的监控系统往往只能知道单个系统的健康状况、一次请求的成功失败，无法快速定位失败的根本原因。解析：分布式链路追踪是 APM 系统的核心概念，在如今微服务架构普及的情况下，一次请求可能会经过多个系统，如图：用户的请求可以通过后台管理系统的认证服务、消息服务和缓存服务以及访问数据库的流程。当其中的某个节点出现异常，如消息服务出现异常，此时缓存服务、调用消息服务和认证服务调用申请也会失败；（1）分布式系统的问题①如果要发现是消息服务出现异常，是比较困难的，因为这个链路比较长而且横跨了多个系统，收集日志的工作也会更加复杂，此时如果想解决问题需要一个系统帮助，②系统在线上的指标是否能被评估出来，这个问题是比较困难解决的。③系统之间的调用变得很复杂，为了方便查看认证服务有多少在被调用，调用关系是否正常，需要详细分析系统之间调用的 top 图，这是一个单靠人工无法解决的问题。④性能分析：一个服务依赖很多服务，被依赖的服务也依赖了其他服务。如果某个接口耗时突然变长了，那未必是直接调用的下游服务慢了，也可能是下游的下游慢了造成的，如何快速定位耗时变长的根本原因呢？⑤链路梳理：需求迭代很快，系统之间调用关系变化频繁，靠人工很难梳理清楚系统链路拓扑（系统之间的调用关系)。为了解决这些问题，最早是 Google 发布论文 Dapper ，根据这个论文推出了一个分布式链路跟踪系统,之后各个互联网公司都参照 Google 的这套系统去实现自己的分布式链路跟踪系统，而这些系统就是分布式系统下的 APM 系统。所以 APM 系统的核心就是分布式链路追踪。3.什么是 Open Tracing各个互联网公司参照 Google 实现了自己的分布式链路追踪，但是各家实现的方式是不一样的，因此如果想从某家的实现替换到另外一家，替换的成本是很高的。于是出现 Open Tracing 这种规范，类似 GP 规范，也是一种抽象的比较高级的 API ，让不同的厂商去实现，使用 GP 规范可以替换底层的实现，无需进行代码的修改，所以 Open Tracing 的普及度比较高，减少了成本。（1）分布式链路跟踪最先由 Google 在 Dapper 论文中提出，而 OpenTracing 通过提供平台无关、厂商无关的 API，使得开发人员能够方便的添加（或更换）追踪系统的实现。下图是一个分布式调用的例子：客户端发起请求，请求首先到达负载均衡器，接着经过认证服务，订单服务，然后请求资源，最后返回结果。首先能看到这个调用关系图，从客户端出发，通过负载均衡，到达权限服务、订单服务和资源服务，调用其中的接口，这张图可以很直观的看出服务之间的调用关系，但是无法告知用户调用的性能的瓶颈。比如看到这张图，有两个问题：第一，这些箭头没有标识出执行的时间，所以无法得知每次调用的耗时是多少。第二，这些调用可能有并行的情况但是在图上无法显示，我们能通过数字感知它的顺序但是并行无法判断。所以，使用 Open Tracing 可以更好的展现一个调用过程，如图：这张图的横轴是时间，在横轴上方每一个调用过程使用不同的色块来表示，可以看到，客户端调用过程所在的节点位置在资源的分配和提供过程上耗时最长，因为它横跨的长度是最长的，所以耗时也是最长的。而这个过程分为两个部分，一部分是容器的初始化和分配存储空间，另一部分是执行启动脚本，第一部分是一个并行执行，即容器的初始化和分配存储空间是并行执行，它们的时间也比较长，同时再执行一个执行启动脚本，加上这两个，资源的分配和提供过程就变得耗时。在这张图上可以看到服务的耗时情况以及服务的并行运行情况，基于 Open Tracing 可以直观的画出这张图，Skywalking也是基于 Open Tracing 来构建。4.主流的开源 APM 产品（1）PinPointPinpoint 是由韩国进行开发的，最大的优点是对代码的无侵入性，即不修改代码，使用 PinPoint 来监控系统，同时 PinPoint 的UI 页面的元素非常丰富，用户体验很好。但是 PinPoint 有一个比较大的缺点，它收集了很多的数据导致整体的性能比较差。（2）SkyWalkingSkyWalking 是 apache 基金会下面的一个开源 APM 项目，在最近几年风头很盛，版本的更迭速度很快，以及由去年的5.0版本升级到今年的6.5.0版本。它是为微服务架构和云原生架构系统设计，所以 SkyWalking 很注重性能的指标，同时它对一些 RPC 框架能够提供支持，如国产的 double 等，它通过探针自动收集所需的指标，并进行分布式追踪。通过这些调用链路以及指标，Skywalking APM 会感知应用间关系和服务间关系，并进行相应的指标统计。Skywalking 支持链路追踪和监控应用组件基本涵盖主流框架和容器，如国产 RPC Dubbo 和 motan 等，国际化的 spring boot，spring cloud。（3）ZipkinZipkin 是由 Twitter 开源，是一款分布式链路调用监控系统，最大的优点是简单易用，Zipkin 本身就与 spring cloud 有很好的继承性，spring cloud 建议在 cloud 框架下使用 Zipkin 来做分布式链路追踪。聚合各业务系统调用延迟数据，达到链路调用监控追踪。Zipkin 基于 Google 的 Dapper 论文实现，主要完成数据的收集、存储、搜索与界面展示。（4）CATCAT 是由大众点评开源的项目，它的版本相对来说古老一些，但是也有自己的优点，如它的报表功能比较完全，是基于 Java 开发的实时应用监控平台，包括实时应用监控、业务监控，可以提供十几张报表展示。一个很大的缺点是它的代码有侵入性，即使用 CAT 必须进行代码的更改。对一些框架的使用进行白点，白点处理后才能进行数据的报告。
-
发表了文章 2022-11-20
Profiler 生成火焰图 | 学习笔记
开发者学堂课程【线上问题排查利器 Alibaba Arthas（下）：Profiler 生成火焰图】学习笔记，与课程紧密连接，让用户快速学习知识。课程地址：https://developer.aliyun.com/learning/course/747/detail/13209Profiler 火焰图内容介绍：一、Profiler 火焰图的目标二、Profiler 的主要作用三、案例四、火焰图的含义五、小结一．目标：生成火焰图介绍：Profiler 命令支持生成应用热点的火焰图。本质上是通过不断采样，把收集到的采样结果生成火焰图。命令基本运行结构是 profiler 命令{命令参数}。二．profiler 主要的作用profiler 主要的作用是用来生成火焰图。Arthas 当中有一条命令，这条命令叫profiler。它支持生成应用热点的火焰图。所谓的应用热点可以用来监听不同的事件,在默认的情况下它监听的是cpu。火焰生成的是cpu的火焰图。它本质上是通过不断的去采样，把收集到的采样的结果生成一张火焰图。profile的命令本身很简单，它的基本结构就是一个Profiler。它后面跟命令，再跟这个命令的参数。并且这个命令参数是可选的，所以用中括号括起来。火焰图的使用很简单，关键是以后生成的火焰图需要能分析和读懂。三．案例首先第一个例子是要先启动 profiler。启动的作用是什么？就是开始记录，从现在开始每隔一段时间获取它的采样的样本，并且生成火焰图。首先输入 profiler。启动profiler的命令叫start。再按回车，它就会开始启动。这个地方会有提示，在默认的情况下就是对cpu进行采样（profiling）。如下代码所示：arthas@10829]$ profiler start Started [ cpu ] profiling[ arthas@10829]$如果想知道它到底支持哪一些事件，也可以通过一条命令：list这条命令可以显示出profiler所支持的所有的事件。按回车，以下看到的就是profiler它支持的一些事件，如下代码所示：[ arthas@10829]$ profiler start Started [cpu] profiling[ arthas@10829]$ profiler list Bjasic events:cpu AllocLockWallItimerPerf events :page -faults context - switches cyclesinstructionscache – referencescache- missesbranchesbranch- mi ssesbus-cyclesL1-dcache- load-missesLLC- load-missesdTLB-load-missesmem: breakpointtrace: tracepoint(arthas@18829]$第一个是基本的事件，有cpu，有锁，有防火墙，等等。下面是其他的一些事件。这些都是profiler所支持的一些事件。它默认的情况下就是第一个cpu的事件。这样可以显示所有它支持的事件。如果想获取它现在到底已经采集了多少个样本，可以通过第三条命令：Profiler getsamples 获得样本，再按回车。这时候它就会获得16个样本。如下代码所示：[ arthas@10829]$ profiler getSamples16( arthas@10829j$随着时间的增长它获取的样本就会越来越多。假设敲两次回车就会变成18个样本，所以时间越长它获取的样本就越多。如下代码所示：( arthas@10829]$ profiler getSamples18(arthas@10829)$另外一条命令叫profiler status。这个命令有什么用呢？它可以用来显示当前的获取的状态，如下图所示就会显示，它已经运行了158秒， 这个指的是cpu。如下代码所示：[ arthas@10829]$ profiler status[perf] profiling is running for 158 seconds[ arthas@10829]$ profiler getSample30(arthas@10829]$可以看出现在已经有30个样本。那这时候想要把它停止怎么做呢？停止它就会生成样本的图。直接输入stop命令：Profiler stop，按回车，回车以后它就会停止，并且它会在如下这个目录下面生成一个svg的图片文件，它默认放在output目录下面。如下代码所示：[ arthas@10829]$ profiler stopprofiler output file: /root/. arthas/lib/3.1.7/arthas/anthas outpu20200322-101225. SvgOK(arthas10829]$那怎么切换目录呢？因为它是一个隐藏的文件，所以要先去找到这个文件，将这个文件复制出来，再切换一下目录，把上面的对勾勾上，它是客户端操作的，就可以进到相应的目录下。并且它是会跟随的。如下图所示：如果现在要想进output的目录下面，这里面就有一个svg的图片，可以双击打开，按允许。就会发现它生成了如下这样的一张图，这个图就是它所生成的火焰图。生成的火焰图它默认输出的是Svg的图片。如果想要生成的是Html文件怎么办？它也可以指定生成HTML的文件。这时只需要在stop后面输入Format html，这是指它的格式，再指定为Html就可以了。如下代码所示：(arthas@10829]$ profiler stop -format html如果敲回车，可以看到它也是输出在同一个目录下面，但是它生成的是一个html的文件。如下代码所示：[ arthas@10829]$ profiler stop --format htmlprofiler output file: /root . arthas/lib/3.1. 7/arthas/anthasoutput/20299322101458 htmlOKrthas@10829]$这时可以看有没有Output目录。在arthas里面寻找，会发现有一个svg的图片，也有个Html的文件。如下图所示：将这个文件双击打开。因为要看的是它的网页，所以假设使用google打开。google所看到的结果是有一点区别的，它生成的是这样的一种格式，这就是它的采样，并且输出的是Html的格式。如下图所示：四．火焰图的含义：火焰图是基于perf结果产生的svg图片，用来展示cpu的调用线。首先看到如下所示的火焰图：它现在是展示cpu的调用站的。从水平方向看，它的坐标是跟数学里面是不一样的，向右边这个方向是X方向，向下面这个方向是Y方向，圆点在左上角。在计算机里面都是这个方向是X这个方向是Y。这里面怎么去看XY轴呢？首先，Y轴方向表示调用的栈一级一级往下走一个栈。每一层实际上就是一个函数，调用栈越深，火焰就越高。顶部就是正在执行的函数，下面都是它的复函数。 X轴就表示抽样的数量。如果一个函数在X轴占据的宽度越宽，就表示它被抽到的次数多，即执行的时间长。这里要注意的是，X轴它不是代表时间，而是所有调用栈合并后，按字母顺序进行排序。火焰图主要是看顶层的函数，哪个函数占据的宽度最大，就表示这个函数是可能存在性能的瓶颈。只要有平顶那就表示它的时间是很耗时的。而颜色没有特殊的含义，因为火焰图表示的是cpu的繁忙程度，所以一般选择暖色调。这就是火焰图的含义。以后可以对它进行一个性能的分析，尽量不要出现平顶。五．小结1.首先第一个 profiler start 。这个是表示启动Profiler，在默认的情况下是生成Cpu的火焰图。2.Profiler list是用来显示所有支持的事件。火焰图的生成，它在Linus电脑上可以，但是在windows下是不能生成的。3.profiler getsamples 是用来获取已采集的样本sample的数量。4.Profiler status 是用来获取或者查看profiler的状态，运行的时间。5．Profiler stop 是用来停止 profiler 生产火焰图的结果，可以指定它的输出目录和输出的格式。输入格式有两种，一种是 svg 另一种是 Html。
-
发表了文章 2022-11-20
Trace 命令的语法和案例 | 学习笔记
开发者学堂课程【线上问题排查利器 Alibaba Arthas（下）：Trace 命令的语法和案例】学习笔记，与课程紧密连接，让用户快速学习知识。课程地址：https://developer.aliyun.com/learning/course/747/detail/13204Trace 命令的语法和案例 内容介绍：一．学习目标二．介绍三．参数说明四．举例五．小结 一.学习目标学习 trace 这条命令的使用，主要功能是对一个方法内部的调用路径进行追踪，并且输出方法路径上的每个节点上的耗时，这一点对于在服务器端诊断服务器的运行时间非常重要，只有在实际的应用场景中才可以看到哪点耗时较大，则在该点进行优化。 二.介绍首先是功能，能够跟踪类指定的方法，整个调用路径，对阅读源代码有帮助，若在开发工具里看源代码逐层点较麻烦，此处会较清晰的将整个调用路径显示出，也会显示性能开销和耗时。这是主要作用。观察表达式的构成主要由 ognl 表达式组成，很多命令都支持 ognl ，合法的 ognl 表达式都可以在trace 命令里使用，同时还可以对执行的平均时间进行过滤，如关注哪部分最耗时，则只显示大于某个时间点的执行方法，只跟踪这样的路径，便于更方便的排除，watch 、stack 、trace 都支持耗时条件过滤。 三.参数说明第一个 class-pattern ，是类名表达式的匹配。第二个 method-pattern ，是方法名表达式的匹配。第三个 condition-express ，是条件表达式，使用 ognl 表达式。还有是[E] ，是大写的，表示开启正则表达式匹配，默认的情况下是通配符的匹配方式。还有是 [n ：] ，设置命令执行的次数。最后一个 cost ，指方法执行的耗时，单位是毫秒。四.举例下面通过案例学习 trace 的应用场景，举四个例子。第一个例子，trace函数指定类的指定方法。是数学游戏，已经进入了追踪，追踪数学游戏中的run方法看效果。[arthas@5769] $ trace demo.MathGame run追踪了数学游戏类里的 run 方法，分析运行结果。ts ＝ 2020-03-21 08：10：07 是时间，thread_name＝main 是线程的名字，run 方法是在主线程里执行的。如下图原代码中 run 方法也是在主线程当中调用的。然后是主线程的ID，ID=1，priority＝5 是线程的优先级，第五级，TCCL＝sun.misc.Launcher $AppClassLoader@70dea4e 是类加载器。[2.14519ms] demo.MathGame:run()是调用run方法的耗时，并且用红色标出了整个执行路径当中最耗时的部分，即计算质因数分解较耗时，并且第一次调用抛了异常。根据原码也可知异常是自己抛出的，如果小于2则会抛异常。//分解质因数public void run() throws InterruptedException {try {//随机生成一个整数，有可能正，有可能负 int number = random.nextint()/10000;//调用方法进行质因数分解List<Integer> primeFactors = primeFactors(number);//打印结果print(number, primeFactors);} catch (Exception e) {System.out.println(String.format("illegalArgumentCount:%3d，"，illegalArgumentCount)+ e.getMessage());}}//打印质因数分解的结果public static void print(int number, List<Integer> primeFactors) {StringBuffer sb = new StringBuffer(number + "=");for (int factor : primeFactors) {sb.append(factor).append('*');}//打印结果print(number, primeFactors);} catch(Exception e) {System.out.println(String.format("illegalArgumentCount:%3d，"，illegalArgumentCount)+ e.getMessage()):}}//打印质因数分解的结果public static void print(int number, List<Integer> primeFactors) {StringBuffer sb = new StringBuffer(number + "="); for(int factor : primeFactors) {sb.append(factor).append('*');}if (sb.charAt(sb.length() - 1) == '*') {sb.deleteCharAt(sb.length(() - 1);}System.out.println(sb);}//计算 number 的质因数分解 public List<Integer> primefactors(int number)! //如果小于2，则抛出异常，并且计数加1 if (number < 2) {illegalArgumentCount++;throw new IllegalArgumentException("number is: " + number + ", need >= 2");}//用于保存每个质数List<Integer> result = new ArrayList<Integer>():因此可得代码一次抛了异常，一次没有，则会继续往下走，执行了同一级的 print 方法，继续又抛异常，没有执行print 方法，再继续执行print 方法，可得跟踪每一个执行路径上最耗时的部分用红色标出了。这是第一个例子。对于第二个例子，刚才执行了4次后强制退出，如果有些方法它调用的次数特别多，可以指定一个-n的参数来指定捕获结果的次数，如让它捕获一次或捕获两次就退出这个命令，则在刚才的基础上加一个-n 2 ，表示捕获两次退出，此时不需按任何操作的 q ，不按 q 也可执行。追踪两次。退出下面也有解释，最多执行两次，程序退出了，现在执行的两次都没有执行打印的方法都抛出了异常，再执行时一次执行打印的方法，一次执行的抛出异常。这是第二个命令。 第三个操作，在默认的情况下 trace.不包含jdk里的函数调用，运行的结果里全部是自己写的方法，因为追踪是追踪自己写的方法，出错也是自己的代码出错，不会将jdk里的执行方法和它的类追踪出，但是有时想知道执行哪些方法，将jdk也显示出，此时需加一个参数 skip ，跳过 jdk 的方法，这个参数是skipjdkmethod ，可以设置为false，默认true 表示跳过，将其包含则trace-skipjdkmethod false demo.mathgame run ，执行两次则会停下，下图是执行的结果。会发现多了 Random 里的 nextint 的方法，这个方法也是在函数里写了的方法，但是之前没有显示，观察原码，run 方法里确实调用了 nextint ，也调用了 primefactors 及print ，总共调用了三个方法，这三个方法在追踪的代码里都可以看到。这是演示的第三个例子。//分解质因数public void run() throws InterruptedException {try {//随机生成一个整数，有可能正，有可能负 int number = random.nextint()/10000;//调用方法进行质因数分解List<Integer>primeFactors=primeFactors(number);//打印结果print(number, primeFactors);} catch (Exception e) {System.out.println(String.format("illegalArgumentCount;%3d，"，illegalArgumentCount) + e.getMessage());}}第四个例子，可以根据调用的耗时情况对时间只显示大于某个时间的最终的方法，此时可以使用 cost 耗时的参数进行操作。也调用两次，“# cost ＞.5”，不一定三次刚好全部大于0.5，先不设置执行的次数，发现不是每一次都大于0.5，没有大于0.5就不会输出，看到的全部都是大于0.5。若改为＞1ms，只要小于1ms都不输出，1是指 run 方法的耗时，并非红色部分。五．小结trace 部分就介绍到此，在实际开发中用的较多，进行小结主要回顾 trace 命令有哪几个参数，如参数的名称及参数的说明，首先第一个参数叫 class-pattern ，表示类名表达式的匹配，第二个method-pattern ，他代表方法名的表达式匹配，还有condition-express，叫条件表达式，是三个必须的参数。也支持正则表达式和命令执行的次数，还支持#cost ，可以用来过滤，是过滤的条件，只追踪满足条件的耗时方法，刚刚演示的是大写，也可能是小写或等于，也有可能，trace 命令就介绍这些。
-
发表了文章 2022-11-20
Arthas 在 Linux 下的安装 | 学习笔记
开发者学堂课程【线上问题排查利器 Alibaba Arthas（上）：Arthas 在 Linux 下的安装】学习笔记，与课程紧密连接，让用户快速学习知识。课程地址：https://developer.aliyun.com/learning/course/746/detail/13184Arthas 在 Linus 下的安装内容介绍：一、Linus 下的安装二、命令三、安装步骤四、小结一、在 linux 里面 Arthas 安装方式在 Linus 下的安装方式和在 windows 下的安装方式是一模一样的。先采用在线的方式去安装。首先把Linus 打开，如下图：再连接 linux，如下图：如下图可以看到已经用 root 进行登录，并且这下面没有特别多的文件。如果采用这种在线的方式去安装，那这个步骤和在windows里面的安装步骤，是一模一样的。二．命令：curl-0 http://alibaba.github.io/arthas-boot.jarjava-jar arthas-boot.jar三、安装步骤：首先先下载jar包，按回车，同样出现的是之前的界面。它下载完后会在当前目录下面有一个Arthas的jar包。如下图所示：接着又执行第二条命令。如果这时侯执行，它必须要保证在linux下有一个 java的启动进程，可以发现它没有找到任何的java启动进程，所以它是运行不了的。如下图所示：1.操作步骤首先要启动一个java进程，在linux里面需要提前安装好Tomcat，先启动tomcat，再去执行它。进tomcat的目录里，启动tomcat。如下图:启动的不一定是 tomcat，只要是一个可以启动的，没有退出来的java进程就可以。现在 tomcat 已经启动了。再执行刚才的命令。注意要回到自己的工作目录下面再运行它，这时候就会发现有java的进程。如下图：这个时候找到的就是tomcat，再输入1，按回车，它会先在本地找有没有安装好的Arthas的包,如果没有就从服务器上面下载。如下图：所以这个linus在线安装的步骤和windows里面在线安装的步骤是一模一样的。只是安装的目录有一点点区别，装好了之后退出Arthas，回到linus里面，如下图：它在linux下面安装成功后是个隐藏的目录。可以看见在这里有一个点，如下图：而在linus里点号开头的文件夹是隐藏的。所以在这里是看不到的，接着搜索带a的参数，这样就可以看见有这两个文件，如下图所示：这两个文件就是Arthas安装好的目录。点进文件里，再进到lib下面，再进到版本号3.1.7里，它的目录很深，这时候就可以找到并且可以使用了。如下图：它的整个安装的过程和在windows里面是一样的，也是一种在线安装。2.离线安装离线安装需要下载一个压缩包，从maven仓库当中下载。比如要下载3.1.7版本，下载的url是：http://maven.aliyun.com/repository/public/com/taobao/arthas/arthas-packaging/3.1.7/arthas-packaging-3.1.7-bin.zin它有完整的arthas的包，大概是十兆，如下图：。可以在Windows里面把它下载好，它是个zip文件。打开浏览器。直接输入http://maven.aliyun.com/repository/public/com/taobao/arthas/arthas-packaging/3.1.7/arthas-packaging-3.1.7-bin.zin这个地址，于是在这个地方出现这个下载的框，如下图：它下载的速度很快，大概是十兆左右。下完以后打开这个目录看一下这就是它的压缩包，如下图：直接解压就能用，解压到任何一个目录都可以。如果要在Linus里面去装也一样，把这个压缩包传到 Linux 上直接解压就可以了。现在回到目录上面，可以看到没有这个压缩包，如图所示：可以把它传上来，找到这个压缩包并把它传到服务器上。传上来以后，在目录下面就有一个压缩包了这个压缩包直接解压就可以使用，可以解压到任何一个目录下或者随便建个目录都可以。这样就可以在解压的目录里面去运行。之后要运行这些东西，主要是Arthas boot，只要找到jar包就可以了。如下图：在这个目录下面执行都是可以的。唯一要知道的是在linux下面如何解压这个zip文件？因为在linus下面用的比较多的都是tar包，如果要解压这个Zip文件，需要通过这条 unzip-d arthas arthas-packaging-3.1.7-bin.zip 命令。-d是指要解压到哪个目录里面去，可以先创建一个这样的目录。然后再解压这个arthas-packaging-3.1.7-bin.zip包就可以了。这两种方式都可以。比如现在正好解压了这个目录，再建一个Arthas的文件夹，把它解压进去。用unzip -d，解压到所选目录，再指定它要解压的压缩包，按回车，这时候就解压完了，进到这个目录里面去看，可以看得到这里的文件，就跟在上面看到的文件是一模一样的。如图所示:这样就相当于安装了两份文件，没有关系，因为它是绿色的，把它删除就可以。这个就是它在linux下面的安装过程。四、小结1.在linux下在线安装的方式与在Windows下面的安装方式相同。2.如果要使用离线的安装方式。要先下载完整的zip包到本地。再解压到任意的目录即可。所以在线安装和离线安装，不管是在windows下面还是在linux下面其实都是一样的。这个就是第二种在 linux下面的一个安装的方式。
-
发表了文章 2022-11-20
在 Windows 下的 Arthas 快速安装 | 学习笔记
开发者学堂课程【线上问题排查利器 Alibaba Arthas（上）：Windows 下的 Arthas 快速安装】学习笔记，与课程紧密连接，让用户快速学习知识。课程地址：https://developer.aliyun.com/learning/course/746/detail/13183在 Windows 下的 Arthas 快速安装内容介绍：一．命令二．Windows 下的安装三．安装过程四．小结接下来介绍一下，怎么样去安装 Arthas。安装 Arthas 有两种方式，一种是在线安装一种是离线安装。Arthas 是 Java 写的，所以它既可以安装在 windows下面，也可以安装在linux下面。首先是在线安装，通过在线安装的方式去安装，在windows下面的一个安装过程，它只要两条命令就可以实现。如下所示：一．命令：1.Curl-0http://alibaba.github.io/arthas/-boot.jar2.Java-jararthas-boot.jar二．Windows 下的安装第一条通过一个 Curl 去下载一个 jar 包。Curl 是在 Windows 和Linus下面都有的一条命令。它的主要作用就是去获取指定的地址上面的资源，并且把它下载下来。它是从 gethub 上下载下来的，那arthas/-boot.jar是什么？整个 Arthas 的使用就是通过jar包运行来使用的，所以这是它的核心。它运行有一个特点，它会先检查本地是否安装了Arthas，如果没安装，那么它就会自动从服务器上面下载整个Arthas安装包，这个安装包大概是11兆左右，这就是在线安装。三．安装过程:先执行第一条命令，打开windows的窗口。在这个命令行窗口下面专门建一个文件夹，假设建一个Arthas的目录，进到这个目录上去执行这条命令，按回车。这时它就开始下载。下载的时候它总共是108K，它左边显示的数字是它百分比的进度，整个下载速度很快。下完以后可以发现这个目录下面有一个jar包。这个jar包就是一个可以执行的jar包，它在执行的时候有个特点，它会检测本地是否有启动的java进程，如果没有启动的java进程，那这个jar包是不能够运行的。如下图所示：所以要先保证本地有启动的进程，例如启动了idea。idea本身就是一个java，运行在java的环境里面。假设现在把它关掉，关掉以后Java没有运行任何的进程。如果这个时候用第二条命令去启动Arthas，是启动不了的，一回车，它就会退出，找不到任何的java进程。所以要先启动一个java进程。如下图：比如说启动idea或者是启动其他的java 进程，只要保证在这个内存里面有一个启动的进程就可以。如果随便打开一个idea项目，不用管它是什么，启动Arthas，按回车，这时候它就会检测到java虚拟机里面是有运行的进程的。如下图所示：假设选二并按回车，它就会去启动Arthas，并且它会发现本地是没有Arthas安装包的，这个时候它就会直接从阿里云的服务器上maven仓库里面下载。如下图所示：下载以后这是它总共的大小10.33mb，如下图：它下载到了以下这个目录下面：打开这个目录并复制，打开资源管理器，可以看到路径就是整个安装好的，如下图所示：这就是一种快速的安装方式，而且是一种在线安装，所以安装速度很快。这个安装过程装好了会建两个文件夹在用户目录下面。它有两个文件夹，一个是点 arthas 一个是logs这两个目录。这个 logs 里面也有arthas的缓存和日志记录文件，这个就是在线的一个最简单的一个安装方式。如图所示是在Windows下面安装好的界面有点像Linux的界面。安装好了后就可以在这里面输入任何的arthas的命令,以上就是它的整个安装过程。四．小结在 windows 下面，采用在线的方式安装 Arthas。第一步就是下载 jar 包，有一个前提要注意就是必须要有一个 java 进程在运行。第一次执行这个 jar 包，它就会自动的从服务器上面下载 arthas，大小大概是11兆。这是一个快速的安装Windows的办法。
-
发表了文章 2022-11-17
Yaml 文件详解、rc、rs 及 deployment 控制器详解 | 学习笔记
开发者学堂课程【Kubernetes 入门实战演练2020版：Yaml 文件详解、rc、rs 及 deployment 控制器详解】学习笔记，与课程紧密连接，让用户快速学习知识。课程地址：https://developer.aliyun.com/learning/course/656/detail/10865Yaml 文件详解、rc、rs 及 deployment 控制器详解Nginx 业务 yaml 文件详解# pwd/opt/k8s-data/yaml/linux36# mkdir nginx tomcat-app1 tomcat-app2# cd nginx/# pwd/opt/k8s-data/yaml/linux36/nginx# cat nginx.yaml1.Deploymentkind: Deployment #类型，是deployment控制器，kubectl explain DeploymentapiVersion: extensions/v1betal #API版本，# kubectl explain Deployment . apiVersionmetadata: #pod的元数据信息，kubect1 explain Deployment.metadatalabels: #自定义 pod 的标签，# kubectl explain Deployment .metadata.labelsapp: linux36-nginx-deployment-label #标签名称为 app 值为linux36-nginx-deployment-label，后面会用到此标签name: linux36-nginx-deployment #pod的名称namespace: linux36 #pod的namespace，默认是defaulespec: #定义deployment中容器的详细信息，kubectl explain Deployment.specreplicas : 1 #创建出的pod的副本数，即多少个pod，默认值为1selector: #定义标签选择器matchLabels : #定义匹配的标签，必须要设置app: linux 36-nginx-selector #匹配的目标标签，template: #定义模板，必须定义，模板是起到描述要创建的pod的作用metadata: #定义模板元数据labels:#定义模板label，Deployment.spec.template.metadata.labelsapp: linux36-nginx-selector #定义标签，等于 Deployment.spec.selector.matchLabelsspec: #定义 pod 信息containers : #定义 pod 中容器列表，可以多个至少一个，pod不能动态增减容器- name: linux36-nginx-container #容器名称image: harbor .magedu.net/linux36/nginx-web1:v1 #镜像地址#command: [" /apps/tomcat/bin/run_tomcat.sh"] #容器启动执行的命令或脚本imagePullPolicy: IfNotPresentimagePullPolicy: Always #拉取镜像策略ports: #定义容器端口列表- containerPort: 80 #定义一个端口protocol : TCP #端口协议name: http #端口名称- containerPort : 443 #定义一个端口protocol : TCP #端口协议name: https #端口名称env : #配置环境变量- name : "password" #变量名称。必须要用引号引起来value: "123456" #当前变量的值- name: "age" #另一个变量名称value: "18" #另一个变量的值resources: #对资源的请求设置和限制设置limits: #资源限制设置，上限cpu: 2 #cpu的限制，单位为core数，可以写0.5或者500m等CPU压缩值memory: 2Gi #内存限制，单位可以为Mib/Gib，将用于docker run --memory参数requests: #资源请求的设置cpu: 1 #cpu请求数。容器启动的初始可用数量,可以写0.5或者500m等CPU压缩值memory: 512Mi #内存请求大小。容器启动的初始可用数量，用于调度pod时候使用第一行 kind 类型，表明我们要创建的类型是什么样的对象资源，可以是deployment、service等等，具体创建什么类型，在该文件中去写。在端口中输入kube^C再输入history可以看到有很多命令类型通过命令kubectl api-resources可以拿到当前的kubectl中部分kind类型创建的kind类型一定在显示出的范围内，不会超出区域，比如上述的deployment第二行apiVersion是要创建对象资源的api版本，例如创建deployment资源，需要访问哪个版本，版本一定要与当前版本一致。具体使用哪个版本，可以在端口中输入命令：kubectl explain deployment去看，如下该版本是apps/v1具体的api版本在deployment下有一个apiVersion，输入kubectl explain deployment.apiVersion去查看。kind也可以通过kubectl explain deployment.kind查看，如图显示出类型类型是 kind 加字符串，字符串可以用图中找，复制打开网页查看官方文档。第三行是metadata，定义pod的元数据信息，元数据信息主要有labels，定义pod的标签，标签可以写多个，使用键值对，左侧是key，右侧是值；name定义pod的名称，namespace可以写pod创建完后属于哪个namespace属于哪个namespace图如下，不同的业务的pod要创建在不同的namespace之内。所以说指定就是根据namespace来指定，具体的可以查看metadata下有哪些字段需要我们写。比如deployment，deployment下有metadata。所以输入kubectl explain deployment.metadata可以看到有namespace，labelsnamespace也可以不写，创建完后则默认为defaule。接下来的spec是用来定义deployment中容器的详细信息，可以使用kubectl explain Deployment.spec查看有哪些字段。有replicas，是基于当前的创建出的pod副本数，即默认创建出多少个pod；有selector，就是定义标签选择器，该标签选择器在新版本中必须要设置，即必须设置 matchLabels，matchLabels可以基于app进行定义，该app必须与template模板下的 app 一致；template 是定义模板，下面定义 metadata、labels、app等输入 kubectl explain deployment.spec.replicas可以看到如果不写，会默认创建一个pod。输入 kubectl explain deployment.spec.template进行查看然后查看 metadata下的 labels，输入kubectl explain deployment.spec.template.metadata.labels可以看到也是键值对，还有官方介绍template下除了metadata还有spec，该spec定义pod信息，里面有containers，定义pod中容器列表，该列表中的选项以-开头。若多个容器可以再写-开头与name平级，就意味着又是新的容器。但是需要注意pod中不能动态的增减容器。输入kubectl explain deployment.spec.template.spec | grep cont 进行查看那么在 pod 在 containers怎么定义呢？首先有 name 指定容器名称。下面的内容就是在给当前的容器定义一堆配置，包括该容器创建时所使用的image镜像，指定的地址可以是harbor的官方地址。接着是command，定义容器初始化的所执行的命令脚本，通常不用写。imagePullpolicy有两个参数可以写，输入kubectl explain deployment.spec.template.spec.containers通常我们会选择 always 和 ifnotpresent。Always是一直拉取镜像策略，什么时候用到呢？之前跑的是 v1版本的代码，如果想升级成 v2，因为 node 里没有该镜像，所以需要从 harbor 中拉取。如果升级的 v2存在bug需要回到 v1，那么v1还是被创建在该节点上，本地已经有该镜像，所以就不需要再从harbor中拉取镜像。如果设置成always，会重新拉取，而ifnotpresent是如果本地存在则不拉取，不存在则拉取。为了保证我们代码更新成功率，不会因为镜像相同而代码不同而出现业务更新失败的问题。即我们这个镜像名称有可能不是 v1，而是release版本的一个image，版本无论更新多少次都是release，但是内部代码已经更新。每次拉镜像都会从gitlab中拉代码，拉完代码后打成镜像，是通过jenkins来完成的。设置为ifnotpresent，如果本地有镜像，就不会重新拉取镜像，代码就不会更新为最新的。所以此时若你们公司的镜像名称是固定的名称，一定要设置为always。如果每打一个镜像都是变化的，可以设置为ifnotpresent。为了避免版本升级但是代码没有升级的问题，可以直接设置为always。但是设置为alwasys会出现：本地节点已经有这个镜像，但是pod删了又重新建一次，那么还是需要到harbor里重新拉取镜像；一个 kubernetes 中可能有多个节点，出现有一个节点出现宕机状态，而导致pod自动迁移，从一个节点迁移到另一个节点，而另一个节点中存在镜像，因为宕机之后探测到该 pod 挂掉后，该节点不能用就会自动调用到另一个节点上重新创建一个新的 pod，这个节点中已经存在镜像但是还会重新拉取一次，然后将新的pod跑起来。接下来的 ports 是定义容器端口列表，通过 containerport 定义一个80端口，再通过containerport定义一个443端口，然后协议是TCP端口协议，还可以给ports起一个端口，这个端口就是一个键值对，给80端口加了一个属性标记，标记该端口走的是http，但实际上它是TCP，是用TCP的方式转化的。当然443端口也是走的TCP，那么这个name可以把它标记为https，说这个是https端口。Env是一个通过文件传递一个环境变量，这个变量通常是name加上这个容器的名称，这个值的为password为123456，主要是容器传递一些变量，env下面是一个列表，还可以传递多个变量名，在下面有第一个变量名是什么，第二个变量名是什么。resources是pot对资源的请求设置和限制设置，每个容器都会限制，一个是硬限制limit，一个是软限制requests。这个软限制通常会设置cpu和内存，这个在之前讲过，容器在创造时，默认服务器是不限制资源限制的，才可以无限制的将资源占完。但可能会导致某一部分的资源消耗比较大，导致整个服务器的资源被消耗完，之后就会影响到当前服务器的使用。这个requests其实并不是起到一个限制的作用。当我们创建容器的时候，客户端节点会进行筛选，筛选的时候会筛选哪些主机，可用资源是否还有这么多，是不是有那么多内存，如果有的话这个主机就在我的可用范围之内，如果没有就在筛选过程中把它去掉了。这是容器创建时的筛选作用，而不是创建之后给它配置一些软限制。在筛选的时候，如果发现没有剩余的内存，机器就会说明没有足够的内存而导致资源的调度失败 。这个limits才是真正的硬限制，限制我们的容器能使用多大的cpu和多大的内存，主要依赖两个值，一个是cpu，一个是memory。cpu的限制，单位为core数，可以写0.5或者500m等CPU压缩值，一个cpu是一千毫核，所以当看到官网文件或是其他类型文件的时候，这个基本都是整数，有的是1.5，或是1500m，这俩个本质是一样的。memory是内存限制，单位可以为Mib/Gib，limits里的memory是限制内存，一般使用的是Mib，例如2000mib等类型的值。将用于docker run --memory参数。2.service如果上面一部分容器想要通过端口对其进行访问是一定离不开service，这个是之前说过内部存在的逻辑的负载均衡，通过web的请求转化为service，service再通过筛选器选出所要的web请求之间转化过去，这个是需要service请求打开NodePort，如果不打开，这个请求就是仅限内部的调用，内部的调用就是其他地方的NodePort，比如这个app3可以调用service来去掉app4，不直接去掉app4是因为它是个容器，它的地址在每次创建完后都会被回收，但由于service是固定的，所以只要找到app3就可以找到app4，这些都是内部端口，如果是外部端口的话就需要portkind: service #类型为serviceapiversion: vl #service API版本，service.apiversionmetadata:#定义service元数据，service.metadatalabels : #自定义标签，service.metadata.1abelsapp: linux36-nginx#定义service标签的内容，这个会用户HPA，k8s动态实现pod扩容缩容。如何进行扩容和缩容呢？这个 HPA 控制器会识别service port的数量，这个数量超过指定范围，比如cpu一直要求在60%以内，但已经超出60%，那么就会通过HPA对他进行扩容缩容。development label：会用于service对development的labels进行筛选和调用，就是筛选development label定义号的标签进行调用，把port加入到service的后端来进行访问其他port的调用。这个的定义是，它一定要和total的service一致，比如这个service linux39，就要把service创建在其里面，不能把service创建在linux40中，会找不到，所以一定要创建在同一个内部service里面。name: linux36-nginx-spec #定义service的名称。此名称会被DNS解析namespace: linux36 #该service肃属于的namespaces名称，即把service创建到哪个namespace里面spec:#定义service的详细信息,service.spectype: NodePort #service的类型，定义服务的访问方式，默认为ClusterIP，service.spec.typeports :#定义访问端口，service.spec.ports。- name: http #定义一个端口名称port: 80 #service 80端口，这个是指定的service端口，可以看到service端口是80就是说开发服务器内部是通过service访问app4，就是这个app3在访问service时就会访问端口然后转换到后端服务器的端口80，所以说是内部服务器的原型，并且在传输层。protocol : TCP #协议类型targetPort: 80#目标pod的端口 nodePort: 30001 #node节点暴露的端口，通过这个来指定name: https #SSL端口port: 443 #service 443端口protocol: TCP #端口协议targetPort: 443 #目标pod端口nodePort : 30043 #node节点暴露的SSL端口selector : #service的标签选择器,定义要访问的目标podapp: 1inux36-nginx#将流量路到选择的pod上，须等于Deployment.spec.selector.matchLabels这些是对容器一些定义。然后再往下是service。如果我们的容器想要通过web的端口对它进行访问的话，那么一定离不开service。它其实是kubernetes内部存在的一个逻辑转化的负载均衡。它可以把通过web的请求转化到service，service再通过它的的筛选器筛选出来。但是需要在副主机打开一个NodePort，如果不打开只能仅限于内部的调用。内部的调用就是别的Port可以调用这个service。比如说这个app3，可以用这个service来调用app4。因为这个app4是个Port是个容器，它的地址在每次被创建完都会被回收，但是这个service是固定的。那这个service是怎么定义的呢？首先也要定义它的类型为service，也要定义service创建时的API版本和元数据。也可以给service起个labels。后面我们会讲到动态扩容，service Iabel主要会用于HPA，k8s动态实现pod扩容缩容。deployment label主要用于 service对deployment的label进行筛选和调用。这个service也有name service。假如说有个linux39，这个有一堆pod，要把service创建到这个里面，而不能创建到Linux40里面，那个时候它会找不到，所以要创建到同一个name service。在service的spec里面要定义详细信息。这个类型叫NodePort，就是给副主机打开一个接应端口。其实除了NodePort还有别的类型。我们可以看到api版本、它的类型、metadata和spac等。在spac里面就要定义type。这里默认是ClusterIP。使用kubectl get service的时候，这个地方看到的就是ClusterIP。默认创建的内部的IP地址。在默认的情况下，这个地址是不能从外网访问，就不能从HAProxy进行负载均衡，也就是不会建立一个四维端口。ClusterIP可以从内网进行调用，默认情况下是不对外的。有效的是EternalName、ClusterIP、NodePort和LoadBalancer。LoadBalancer是一个复杂均衡器。创建 服务 时，你可以选择自动创建云网络负载均衡器。 负载均衡器提供外部可访问的 IP 地址，可将流量发送到集群节点上的正确端口上 （ 假设集群在支持的环境中运行，并配置了正确的云负载均衡器驱动包）。你还可以使用 Ingress 代替 Service。请务必注意，此功能的数据路径由 Kubernetes 集群外部的负载均衡器提供。可以通过在服务的清单文件中将 externalTrafficPolicy 设置为 Local 来激活此功能。比如：apiVersion: v1kind: Servicemetadata: name: example-servicespec:selector: app: example ports: -port: 8765 targetPort: 9376 externalTrafficPolicy: Local type: LoadBalancer对网络其他的主机来访问的话，那么也要把他指向NodePort。通过NodePort在service副主机上建立一个端口，所以后面是通过ports来定义访问端口。这个都那口里面有这么几个实例。端口名称其实无所谓，这个ports定义的是service的端口。为什么会有service端口呢？其实指的就是在我的集成内部，别的服务想要通过service访问port。这个port的端口可能是8080，但是service可以让它监听到80。所以app3在访问service的时候就访问的是80端口，然后就会转化到后端服务器的80端口，所以他是一个内部负载均衡器。这个协议类型要走TCP。如果port是8080端口的话那么targetPort就要是8080。如果NOdePort再开一个端口，这个通常会比较大，比如说30001。访问的过程是这样的：用户访问防火墙，这个防火墙220.1.1.1:80把公网地址传递给HAProxy的一个VIP，我们为了保障负载均衡能够可用，我们会做两个VIP，即两个HAProxy。第一个HAProxy会监听一个内网地址，比如是172.20.100.100:80。HAProxy再把它转换到30001，这个30001再转换到service 80，再转换给port的8080，这样port容器就收到用户的请求了。https也与http一样。这个select至关重要。前面写了许多多东西，这些东西到底转换到那个port上。是service的标签选择器,就是定义好service要把用户访问的请求转化为的目标pod。这个app叫1inux36-nginx将流量路到选择的pod上，必须等于Deployment.spec.selector.matchLabels，就是spec下的selector和app必须和template下的labels和app相等。如果不相等就会告诉这个文件不可使用，所以这三个地方的内容必须一样。这样service会把所有请求转化为app标签的pod上，这就是通过service创建的容器。这时候在服务器上使用kubectl get ep，看看它的后端服务器是哪些。我们在之前的配置文件里指定了它们的label标签。进入编写文件可以看到service 的app等于nginx，等于template的nginx，等于selector下面的nginx。如果我们把nginx写错了，先把它的服务删了，看是否能够执行比如说改成nagix-linux39，这样一改文件就不符合标准了，因为matchLabels和metadata的值不一致导致无法使用。当报错的时候需要仔细查看哪里出错，报错内容现实spec下的template的matadata下的labels无效，显示和template里的值不一样，无法匹配。改正方法，可以选择将上面的linux删除掉，或是在下面的内容中加上，总之俩个必需保证一样才可以。这样就可以创建了，但是访问不了。Nagix-service端口是30004，这样是不通的，在筛选的时候，这个标签没有labels，里面就几个容器，没有符合条件的pod，就筛选不成功。这就导致这个Nginx service没有后端服务器，所以使用Get ep的时候，nginx的endpoint是没有的。就要把select标签改成某些port中的label相同的值就能找到。加上后apply一下就可以，如果不apply的话，它是不会生效的，所以之间访问3.109.1004它是不通过的，无论是怎样，浏览器访问等都不会生效。通过语句kubectl apply -f nginx.yml应用一下，会进行修改前后的对比，可以看到原来development的位置没有发生改变，但是service发生了改变后，就可以找见文件，就可以在浏览器里进行访问。所以在配置过程是比较简单，但是稍微不注意就会导致服务无法访问。如果已经报错，更换是没有用的，只能根据当前报错的信息去排除错误。有时候会说某一个端点无法使用，说已经被占用了，会从k8s删除一个服务，删除后立即创建是创建不好的，短时间内是不能够把数据传完的，就是端口还未被回收，需要等待一段时间才能够创建好。假设现在删完后直接操作，会看到端口还未被回收，要确保service回收之后，才能创建。这个问题在正式环境或是pod比较多的情况下是延迟时间是比较多的。这个是删除看上去比较简单的，在整个k8s中是要几个服务的交接。交接是给某个pod下指令给服务器，k8s把指令从etcd上，这个指令是kubernetes master标记的etcd的值，到操作把node上的值监听，把3004取消监听。这个取消监听不是kubernetes master完成的事情，而是HAProxy，这个时候要kubernetes master发送指令，接到之后才能把本机的端口监听去掉。就是把之前的antitable删掉，删掉后就无法访问。kubernetes master和n ode 节点的交互是要几个步骤的，会在后期进行讲解。上面就是删除和创建的操作。yml文件每个对象都有三大属性：元数据metadate、规范spec和状态status。spec和status的区别：在yml文件中spec是一个期望值，但是当最后pod创建后的是所得status为当前的运行值。允许值就是基于yml创建的。会有一个在创建pod时的一个记录，经过了几个步骤，第一步就是调度，使用默认的调度器以及消息（每个步骤执行的过程或结果，结果会通过日志打开出来），结果是调度成功，之后会说分配到哪一个节点；pulled是当前哪一个节点有影响，有影响的话看使用的策略是什么，会拉影响。之后会创建容器，最后启动。会看见pod的生命周期。在知道yml文件如何写后，在这里讲述pod怎么通过yml文件创建以及控制服务器的概念。3.Pod概述：Pod是k8s中最小单元；一个pod这可以运行一个容器，也可以运行多个容器；运行多个容器的话，这些容器是一起被调度的；pod的生命周期是短暂的，不会自愈，是用完就毁灭的实体；一般我们是通过Controller来创建和管理pod的。所以在创建pod会引入以下几个控制器的概念，Controller ：控制器Replication Controller 和 ReplicgSet，这俩个是个组合，到目前为止已经被deployment取代了https://kubernetes.jo/zh/docs/concepts/overview/working-with-objects/labels/ #标签选择器 这个控制器怎么控制pod的运行，就会涉及到标签选择器，就是一个label标签，控制器会基于标签选择器找到pod，再对pod进行什么操作，https://kubernetes.io/zh/docs/concepts/workloads/controllers/replicationco ntroller/# Replication Controller 和Replica SetReplication Controller注意：先推荐是用配置ReplicaSet的deployment，要保证有一个pod是可用的，ReplicationController确保在任何时候都有特定数量的pod副本处于运行状态，换句话说，Replication Controller确保一个pod或一组同类的pod总是可用的。Replication Controller如何工作当pod数量过多时，Replication Controller会终止多余的pod，pod数量太少时，Replication Controller将会启动新的pod。与手动创建的pod不同，由Replication Controller创建的pod在十八、被删除或本种植时自动替换例如，在中断性增护(如内抗开放)之后，它们pod会在节点上重新创建。因此，即使您的应用程序只要一个pod，您也应该使用 ReplcationContrOller 创建. Replication Controller 类似于进程管理器，但是 RepleatonController不是监控单个节点上的单个进程，而是监控跨多个节点的多个pod。在讨论中， Replication Controller 通常缩写为“rc”，并作为kubectl命令的快捷方式，一个简单的示例是创建一个 ReplicationController 对象来可靠地无限期地运行Pod的一个实例。更复杂的用例是运行一个多副本服务(如web服务器)的若干相同副本。所有环境描述文件、配置（包括nginx配置）等都哟啊以代码的形式放在GitHub上，尽量不要保存在本机文件上，在guihub上可用进行后期的版本控制环境隔离，就是不同业务的pod在不同的节点上。其他的业务通过nginx进行逻辑隔离，所以跑到哪一个物理机就是看a项目和b项目的不一样。a、b项目的环境不一样就是逻辑隔离，把他们从物理和逻辑上都隔离开，这就可以创建服务了Deployment- https://kubernetes.io/ あさ/docs/concepts/workloads/ controllers / deployment /· StatefulsetDaemonsetJob，一般不回应job，用的deployment居多在知道yml文件如何写后，在这里讲述pod怎么通过yml文件创建以及控制服务器的概念。此时还涉及到yml文件如何保存的问题，这个服务通过yml文件创建的，肯定是可以保存的。通常情况下会在opt中创建一个目录k8s-date,其中又分为两个目录dockerfile和yml。yml其中又有两个目录，一个是namespaces。来看几个示例文件，第一个示例是怎么通过rc来创建deploment，修改配置将replicas改为1，添加namespace:linux39，加上后会出现selector。然后进行创建输入kubectl apply -f deployment.yml，这样nginxpod就跑起来了。输入kubectl get pod可以查看，输入kubectl get pod -n linux39可以查看到namespace里的pod信息，而linux39中正好有一个pod处于创建状态。跑起来后输入vim rs.yml进行访问,进入到replicaset控制器，可以删掉，输入kubectl delete -f deployment.yml，再输入vim rc.yml,它和deployment.yml区别在于deployment中可以通过如下多种方式去匹配但是replicationController不支持该写法，只支持传统格式ReplicationController的.spec.selector字段是一个标签选择器。ReplicationController管理标签与选择器匹配的所有pod。它不区分它创建或删除的Pod和其他人或进程创建或删除的Pod。这允许在不影响正在运行的Pod的情况下替换 ReplicationController。还有一个区别是deployment支持很多功能：比rs更高一级的控制器，除了有rs的功能之外，还有很多高级功能,，比如说最重要的:滚动升级、回滚等。但是replication Controller的selector标签只能为=或者!=。此外还有replicaSet副本控制集，和副本控制器的区别是：对选择器的支持（selector还支持in notin）。而官方建议使用deployment，一个Deployment控制器为Pods和ReplicaSets握供描述性的更新方式。描述Deployment中的—_desired state，并且Deployment控制器以受控速率更改实际状态，以达到期望状态。可以定义Deployments 以创建新的ReplicaSets，或删除现有Deployments，并通过新的 Deployments使用其所有资源。再来演示：输入kubectl get pod -n linux39显示没有资源，创建rc，输入kubectl apply -f rc.ymlkubectl get pod -n linux39vim deployment.yml^Ckubectl delete -f rc.ymlvim rc.yml修改添加上namespace:linux39添加完后再重新创建输入kubectl apply -f rc.ymlkubectl get pod -n linux39这样就创建完成。ReplicaSet是下一代的Replication Controller。ReplicaSet和Replication Controller 的唯一区别是选择器的支持。Replicaset支持新的基于集合的选择器需求，这在标签用户指南中有描述。而 Replication Controller仅支持基于相等选择器的需求。ReplicaSet确保任何时间都有指定数量的Pod副本在运行。然而，Deployment是一个更高级的概念，它管理Replicaset，并向Pod提供声明式的更新以及许多其他有用的功能。因此，我们建议使用Deployment而不是直接使用ReplicaSet，除非您需要自定义更新业务流程或根本不需要更新。来梳理一下图：Deployment可以实现对pod代码升级的特定方式，比如回滚等等，至于如何实现，在以后会讲解如何使用脚本来实现代码升级和回滚。比如deployment更新：了解一下更新：仅当Deployment Pod模板(即.spec.template)时，才会触发Deployment展开，例如，如果模板的标签或容器镜像已更新，其他更新(如扩展Deployment)不会触发展开。按照以下步骤更新Deployment :让我们更新 nginx Pods，以使用nginx:1.9.1镜像，而不是nginx:1.7.9镜像。kubectl --record deployment.apps/nginx-deployment set imagedeployment.v1.apps/nginx-deployment nginx=nginx:1.9.1输出: ```shelldeployment.apps/nginx-deployment image updated```或者，可以‘edit’ Deployment 并将‘.spec.template .spec.containers[ ].image’从‘nginx:1.7.9’更改至‘nginx:1.9.1'。```shellkubectl edit deployment.v1.apps/nginx-deployment```等等当然k8s中有很多容器，可以理解为这些控制器他们的操作对象是运行在k8s中的n个pod，每个控制器对pod进行维护代码升级等。无论是使用replicationController还是replicaSet还是deployment都是对代码实现回滚升级等功能。接着讲解控制器，刚才我们创建了一个容器，该容器是基于replicationController创建的输入vim rc.ymlkubectl get pod -n linux39结果有两个pod查看pod信息kubectl describe pod ng-rc-8whpn -n linux39可以看到它的一些信息：name、namespace等等再来讲解rs，输入kubectl delete -f rc.ymlvim rc.ymlkubectl apply -f rs.ymlget pod -n linux39结果显示没有找到namespace，再来删除Kubectl delete 0-f^CKubectl get pod将这两个跑在同一个namespace内，输入kubectl delete -f rs.ymlkubectl get podvim rs.yml再来修改，加在name下输入namespace：linux39再来创建kubectl apply -f rs.ymlget pod -n linux39可以看到有两个前端服务。再来查看镜像，输入vim rs.yml镜像直接调用的官方镜像nginx，再来查看是否能跑起来，输入Kubectl get pod -n linux39结果显示running，那么删除呢？输入Kubectl delete -f rs.yml再来尝试create命令，输入Kubectl create -f rs.yml也可以创建，而且也可以跑起来，输入Kubectl get pod -n linux39如果此时想要修改yml文件的配置，想要配置重新生效，输入Vim rs.yml将pod数量改为3个，改完后再来创建，输入Kubectl create -f rs.yml结果显示报错，不能创建。所以通过create创建的pod，后期如果想要修改并且生效的话，需要在第一次创建时添加参数，所以这种情况下只能删除第一次创建的pod，输入Kubectl delete -f rs.yml删完后在重新创建才能将pod改为3个Kubectl create -f rs.ymlKubectl get pod -n linux39如图为三个再来添加一个选项保存配置，输入kubectl create -f rs.yml --save-config=true比如将pdo再修改为5个，输入vim rs.yml将pod修改为5个kubectl apply -f rs.ymlapply可以实现创建pod功能此外还有一个选项record可以实现版本功能，输入kubectl create -f rs.yml --save-config=true --record=true打开之后先验证 pod 是否被创建，输入kubectl pod -n linux39可以看到正在被创建，再进入配置将pod改为3个Kubectl get pod -n linux39Kubectl apply -f rs.ymlKubectl get pod -n linux39可以看到变为3个。此外 pod 在三个模式下都不能删掉，可以通过删掉控制器，例如输入kubectl get deployment -n linux39kubectl delete deployment nginx-deplyment-n linux39get pod -n linux39可以看到 pod 正在删除中
-
发表了文章 2022-11-17
Kubeadm 升级 k8s 至 v1.17.4及运行 nginx+tomcat 并实现动静分离 | 学习笔记
开发者学堂课程【Kubernetes 入门实战演练2020版：Kubeadm 升级 k8s 至 v1.17.4及运行 nginx+tomcat 并实现动静分离】学习笔记，与课程紧密连接，让用户快速学习知识。课程地址：https://developer.aliyun.com/learning/course/656/detail/10862Kubeadm 升级 k8s 至 v1.17.4及运行 nginx+tomcat 并实现动静分离内容介绍一．K8s 升级二．k8snode 服务三．测试与运行四．kubeadm 其他命令一．K8s 升级1.升级条件刚遇到版本出现 bug 或者功能不能满足业务的需求涉及到升级，以此来解决功能的不足或缺陷。2.流程初始化升级测试环境或开发环境，容易升级，不用管理业务或者不用考虑用户的访问。升级生产环境时，需要选择升级时间，一般选择凌晨（因为此时访问的人较少）升级方式:kubeadm(较容易)ansible(较容易)证书签发：dec/kubernetes/pki/(可查看一些证书)手动安装：比较复杂，考虑开发证书，牵动服务等。3.K8s 群集升级升级 K8s 集群必须先升级 kubeadm 版本到目的 k8s版本,也就是说 kubeadm#是k8s 升级的"准升证”。kubeadm 命令先升到需要的 kubeadm 版本，再升级 k8s。有新的 kubeadm 才能升级k8s"准升证”:要求严格,有新的 kubeadm 才有新的 k8s4.升级 k8smaster 服务:在 k8s 的所有 master 进行升级，将管理端服务 kube-controller-manager.kube-apiserver.kubeschedulerkubeproxy。直接安装apt-cachemadisonkubeadm:查看仓库可以装进哪些新版本aptinstallkubeadm=1.17.4.00：把kubeadm安装成1.17.4版本Kubeadm-version 验证版本：此时可以通过1.17.4版本的 Kubeadm 安装1.17.4版本的 k8s。通过 Kubeadm--help的upgrade 参数：升级集群到新的版本apply：升级集群到指定版本diff：运行到不同地方，不同版本信息（不升级）--dry-run 测试运行Node：升级node结点Plan：检查升级计划给出清单：对比当前版本：1.17.2可用版本1.17.4CoreDNS版本无变化：已升级至最新版本Kubeadmupgrade--help检查当前升级版本5.验证当 k8s 前版本:#kubeadmversionKubeadmversion:&version.Info(Major:"1",Minor"17"GitVersion:"v1.17.3",GitCommit:"06ad960bfd03b39c8310aaf92d1e7c12ce618213"GitTreeState:'clean",BuildDate:"2020-02-11T18:12:12Z",GoVersion:"g01.13.6",Compiler:"gc",Platform:"linux/amd64"6.各master安装指定新版本kubeadm:#apt-cachemadisonkubeadm#查看k8s版本列表，#apt-getinstallkubeadm=1.17.4-00#安装新版本kubeadm#kubeadmversion#验证kubeadmversion版本Kubeadmversion:&version.Info{Major:"1"Minor:"17",GitVersion:"v1.17.4",GitCommit:"8d8aa39598534325ad77120c120a22b3a990b5ea",GitTreeState:"cean",BuildDate:"2020-03-12T21:01:11z",GoVersion:"go1.13.8",Compiler:"gc",Platform:"linux/amd64"}7.Kubeadm 升级命令使用帮助#Kubeadmupgrade--helpUpgradeyourclustersmoothlytoanewerversionwiththiscommandUsage:kubeadmupgrade[flags]kubeadmupgrade[command]AvailableCommands:applyUpgradeyourKubernetesclustertothespecifiedversiondiffShowwhatdifferenceswouldbeappliedtoexistingstaticpodmanifests.Seealso:kubeadmupgradeapply--dry-runNodeUpgradecommandsforanodeintheclusterplanCheckwhichversionsareavailabletoupgradetoandvalidatewhetheryourcurrentclusterisupgradeable.Toskiptheinternetcheck,passintheoptional[version]parameter。8.升级计划#Kubeadmupgradeplan#查看升级计划9.开始升级#kubeadmupgradeapplyv1.174#master1#kubeadmupgradeapplyv1.17.4#master2#kubeadmupgradeapplyv1.17.4#master3在 master 上升级，在上面安装 kubeadm 命令。在安装之前，我们需要查看在 kubernetes 界面点击 pods,将，Namespace 切成 kube-system 默认的管理端运行的 namespace。能看到 kubernetes 运行的版本。查看到版本是1.17.2会获取到当前的版本。然后匹配 kubeadmversion 版本。对比从版本一升级到版本二会有哪些差异。是否确认升级版本y每个分别升级，否则可能会影响运行 Kubectlgetpod-a有些容器正在被创建--正在升级 Master1已经更新成功升级谁把谁摘走下载定向手动下载定向，下载定向过后升级速度提升Dockerimages 检查定向下载（没有全部下载完毕）可以使用脚本下载定向或手动下载定向。脚本:k8s-1.17.4-images-download.sh只有 k8s 管理端的定向改变。edce 等都没有改变。Bashk8s-1.17.4-images-download.shDockerpull 手动下载镜像升级成功会进行通知Yourclusterwasupgradedto“v11.17.4.enjoy”Dockerps升级完成后查询镜像已经下载很多把创建容器的镜像换成新的版本，换成1.17.4镜像等待102升级完成升级完成后可以进入master1进行验证。如果容器的启动没有问题。在 haproxy 将102和103挂上，将101摘下。将重haproxy启，重启后在进行升级将101摘下 ak 可以访问吗？会把请求转发给 haproxy后端服务器10.验证镜像二．k8snode 服务1.升级 k8snode 服务升级客户端服务 kubectlkubecletKubectlversion 命令更新需手动安装aptcachemadisonkubelet把 kubeadm 的和 kubeadm 词条命令安装上。2.验证当前 node 版本信息Node 节点还是1.16.1的旧版本#kubectlgetnodeNAMESTATUSROLESAGEVERSIONkubeadm-master1.magedu.netReadymaster143mv1.17.3kubeadm-master2.magedu.netReadymaster137mv1.17.3kubeadm-master3.magedu.netReadymaster136mv1.17.3node1.magedu.netReady115mV1.17.3node2.magedu.netReady113mv1.17.3node3.magedu.netReady113mv1.17.33.升级 node 节点配置文件在控制端#kubeadmupgradenode--kubeletversion1.17.4[upgrade]Readingconfigurationfromthecluster..[upgrade]FY:Youcanlookatthisconfigfilewith'kubectl-nkube-systemgetcmkubeadm-config-oyaml'[upgrade]UpgradingyourStaticPod-hostedcontrolplaneinstancetoversion"v1.174"..Staticpod:kube-apiserver-kubeadmmaster1.magedu.nehash:9b27fdd11086b9631e6ecf20b210a801Staticpod:kube-controller-manager-kubeadm-master1.magedu.nethash:9f58505c8c69357c59a517de8dd0d70eStaticpod:kube-scheduler-kubeadm-master1.magedu.nethash:0621ae8690c69d1d72f746bc2de0667e[upgrade/etcd]UpgradingtoTLSforetcd[upgrade/etcd]Nonfatalissueencounteredduringupgrade:thedesiredetcdversionforthisKubernetesversion"v1.17.4"is"3.4.3-0",butthecurrentetcdversionis"3.4.3".Won'tdowngradeetcd,insteadjustcontinue[upgrade/staticpods]WritingnewStaticPodmanifeststo"/etc/kubernetes/tmp/kubeadm-upgradedmanifests356491761W032214:27:2945807688620manifests.go:214]thedefaultkubeapiserverauthorization-modeis"Node,RBAC";using"Node,RBAC"[upgrade/staticpods]Preparingfor"kubeapiserver"upgrade[upgrade/staticpods]Currentandnewmanifestsofkube-schedulerareequal,sippingupgrade[upgrade]Thecontrolplaneinstanceforthisnodewasuccesfullyupdatedl(upgrade]Usingkubeletconfigversion1.17.4,whilekubernetes-versionisv1.174[kubelet-start]Downloadingconfigurationforthekubeletfromthe"kubelet-config-1.17"ConfigMapinthekube-systemnamespace[kubelet-start]Writingkubeletconfigurationtofile"/var/lib/kubelet/config.yaml"[upgrade]Theconfigurationforthisnodewassuccessfullyupdated![upgrade]Nowyoushouldgoaheadandupgradethekubeletpackageusingyourpackagemanager.升级master每个 master 都升级成1.17.4（使用 kubeadmadm）1.先安装指令版本的 Kubeadm2.Kubeadmupgradeplan 查看升级计划3.Kubeadmupgradeapply1.17.4不检查直接升级也可以（保证无错误）容器正在被创建升级服务端，此版本由 kubectl 控制验证服务端是否升级成功查看 pod 使用的镜像，版本是否为1.17.4Pod 启动时所加载的参数，找到官方的二进制，把二进制放入某地址，直接通过本地运营起来.kube-apiserver-advertise-sddress=172.31.3.102-allovprivileged-true-authorization-modemNode,RBAC-client-cafile-/etc/ubernetez/pki/ca.ert-ensble-adnissiom-plugins-NodeReatriction-enable-bootstrap-token-auth=true-etcd-cafilerlete/kubernetes/pki/etcd/ca.crtetcd-ceztfile/etc/kubernetes/pki/apiserver-etcd-client.crdtkeytilem/etc/zubernetes/pki/apisexver-etcd-client.keyetcdsarver-https://127.0.0.1:2379cwemDort=0kubelet-client-certificat/tckubernetna/pki/aoinexver-kublet-client.et"xubelet-client-key-/etc/ubernetet/pki/apiezverkubeltclient.keykubeletprefenzed-address-typeInternall,ExternallP,Hostnkeproxy-client-cert-file/etc/kubexrntespki/fzontroroslient.crtproxyclient-keyfile-/tc/rubcrnetes'pki/fantrroxyrelient.keyrequestheader-allowednanes=frontmromrelientrequestheadex-client-cafileetc/kubernntsrkiitrontroryr-ca.crtrequestheader-extra-headersprefiremoteEtrarequeatheadercroupmheadersKkenoteGrouprequeatheadermusernaseheaderXRenot-UtereCure-port=0443sevice-account-keyfil/etc/rubernetes/pki/sa.pubmservice-clurteriprange192.108.0.0/20wmtlamcertfilo-/etc/kubernetes/pki/apiserver.crttiprivatekeyfile/etc/kubernetes/pki/apiserver.key跑在各个节点上的 kubelet 成为1.17.4版本，所以显示 node 节点的版本也是1.17.4Kube-proxy 用镜像跑用镜像查看是否存在1.17.4的 Kube-proxy总 pod 有6个4.各 Node 节点升级 kubelet 二进制包:包含 master 节点在的 kubectl、kubelet 也要升级。AptInstallkubelet=1.17.4-00kubeadm1.17.4-00kubect1=1.17.4-00验证最终版本。在各个 node 节点使用 aptinstallkubectl=1.17.4-00Node 节点两个命令KubeadmkubeletKube 磁条是客户端相同版本客户端的兼容性是最好的用1.17.4的 kubeadm 磁条版本访问1.17.4的 master 是最好的三．测试与运行1.测试运行 nginx+tomcathttps://kubernetes.io/zh/docs/concepts/workloads/controllers/deplyment/测试运行 nginx,并最终可以将实现动静分离使用1.17版本的原因：该版本兼容性做好官网查找创建 Deployment下面是一个 Deployment 示例。其中创建了一个 ReplicaSet，负责启动三个 nginxPods：controllers/nginx-deployment.yamlapiVersion:apps/v1kind:Deploymentmetadata:name:nginx-deploymentlabels:app:nginxspec:replicas:3selector:matchLabels:app:nginxtemplate:metadata:labels:app:nginxspec:containers:-name:nginximage:nginx:1.14.2ports:-containerPort:802.运行 Nginx:#pwd/opt/kubdadm-yaml#catnginx/nginx.ymIapiVersion:apps/v1kind:Deploymentmetadata:namespace:defaultname:nginx-deploymentlabels:app:nginxspec:replicas:1selector:-matchLabels:app:nginxtemplate:metadata:labels:app:nginxspec:containers:-name:nginximage:nginx:1.15.4ports:-containerPort80kind:ServiceapiVersion:V1metadata:labels:app:magedu-nginx-service-labelname:magedu-nginx-servicenamespace:defaultspec:type:NodePortports:name:httpport:80protocol:TCPtargetPort:80nodePort:30004selector:app:nginxI#kubectlapply-nginx/nginx.yml实行回滚---分割符前面是一对段配置，后面是独立的另外一段配置Kubectlapply-fnginx-yml 运行查看容器是否能通每个容器分配不同页面进入目录编辑文件将每个pod 分配不同页面用不同浏览器访问的pod不同通过haproxy代理nodeport不会让用户访问不会让防火墙直接转入nodeport,因为防火墙不具备一对多的关系。只能把一个共享地址翻译成一个内网地址，也不具备状态检测功能。修改方法：可以加入监听生成249ip挂1/2个服务器不影响访问。249没有编辑配置文件，生成一个249的IP，用249作为某个业务项目的入口，在这个基础上进行动静分离。此时附带平衡被完成。直接访问 IP 即可，通过249运行解释。Linux39可以访问很多个域名。放入目录 kubdadm-linux39mkdirnginx-yml进入创建 nginx-yml在 yml 中通过 image 指定镜像能够实现内外网通信，Nds 调用 tomatService示例：apiVersion:v1kind:Servicemetadata:name:default-subdomainspec:selector:name:busyboxclusterIP:Noneports:-name:foo#实际上不需要指定端口号port:1234targetPort:1234---apiVersion:v1kind:Podmetadata:name:busybox1labels:name:busyboxspec:hostname:busybox-1subdomain:default-subdomaincontainers:-image:busybox:1.28command:-sleep-"3600"name:busybox---apiVersion:v1kind:Podmetadata:name:busybox2labels:name:busyboxspec:hostname:busybox-2subdomain:default-subdomaincontainers:-image:busybox:1.28command:-sleep-"3600"name:busybox3.运行 tomcat#pwd/opt/kubdadm-yaml#cattomcat/tomcat.ymlapiVersion:apps/v1kind:Deploymentmetadata:namespace:defaultname:tomcat-deploymentlabels:app:tomcatspec:replicas:1selector:matchLabels:app:tomcatDockerpulltomcat访问经过负载平衡到 nodeport 交给 n-sservice 再到 n-sport。如果是自己的请求自己处理若不是自己的请求查看如何转化给 tomcat。涉及到kubeDNS里面的服务是如何做调用。Dockerrun-it--人们-怕8080：8080tomcat做镜像进入查看目录Userlocaltomcat创建app，Mkdirapp写入 index.htmlViapp/index.html确认可以访问 tomcat 首页文件,容器便可以使用把 tomcat 容器跑到 kubeNDS方法：创建 dockerfile 目录，进入目录，vimdockerfile,在本地创建目录 app，写页面Tomcatappimagewebpage 进行简单测试，把镜像传到本地harbor.Linux39.com/Linux39.com/tomcat:app查看此镜像页面能否访问成功后将镜像传：DockertageDockerpushFORMtomcatADD./app/user/local/tomcat/webapps/app把 n-s 目录拷到当前目录下Port：sercive 的 portNodeport：只能用一次创建完成后，getport 查看 tomcat 是否运行成功数量写一个避免占用资源过多。此时查看是否可以访问 tomcat,在浏览器访问172.31.3.108:30005发现，此时已经寻找到 tomcat，单位添加app2.测试访问 web 页面172.31.3.108:30005/app（访问成功）此时 nginx 与 tomcat 已经运行,但是 tomcat 作为被 nginx 调动的服务,不被直接调用30005只是临时端口用于测试对外端口只需要n-s把tomcat注释掉：此时再次访问失败3.web 界面验证 podKubectlexec-it 进入磁条安装 vim 命令直接在容器安装进入 pod 找到 nginx 配置文件进入 conf.d 编辑 default.confVimdefault.conf写入 location一旦访问 app 就转化到 tomcat 中Kubectl 磁条 getservice如何分配 service域名必须解析检查从 nginx 能否解析 servicename验证解析结果是否是从 tomcat 查看的结果Service 在 tomcat 是80所以是相同的。请求此端口会被 service 转化到 tomcat80Kubectldescribeservice查看 service 后端服务器10.10.4.12：8080Port-portnginx-nginxnginx-service4.从dashboard 进入容器仅需要把 atp 的请求已http的方式转化到service,不用写tomcat容器地址，因为后期容器地址一般会发生变化。只要保证从内网到外网，从外网到内网是正常运行。四.kubeadm 其他命令1.token 管理:#kubeadmtoken--helpcreate#创建 token,默认有效期24小时delete#删除 token.generate#生成并打印 token,但不在服务器上创建，即将 token 用于其他操作 list#列出服务器所有的 token.若过期：kubeadmtokencreate[token]可以直接创建若 token 不安全可以进行删除操作 Delete2.reset 命令:#kubeadmreset#还原 kubeadm 操作。还原 kubeadm 产生的数据kubeadm 有3个 master关机（poweroff）查看 kubeadm 管理端使用是否正常Kubectlgetnode 验证，查看关闭一个节点集群是否被影响。不影响关闭两个会受到影响，即只可以关闭一个。检测出现异常关闭两个会受到影响，即只可以关闭一个。出现报错2个节点都不可以关闭，3个节点可关闭1个，5个 master可以关闭2个节点。Node 节点正常运行，不被影响。
-
发表了文章 2022-11-17
阿里云 RDB（1）｜学习笔记
开发者学堂课程【阿里云新手上云实战演练：阿里云 RDB】学习笔记，与课程紧密联系，让用户快速学习知识。 课程地址：https://developer.aliyun.com/learning/course/655/detail/10852阿里云 RDB 内容简介：一、SSL 证书二、建站三、阿里云 RDB四、使用 RDS 做 WordPress 数据库五、白名单 一、SSL 证书1、购买证书购买证书页面如下：分类必须选有DV，DV下面就有免费版。现在把 DV单独列出来，买的时候直接买免费版，免费版的和前面这几个有以下区别：（1）通配符通配符即所有的域名都支持。比如买的是二级域名，然后所有的三级域名都支持，四级域名就不支持了，就只支持前面那一个。比如买了.com，那么所有的a.com，b.com，c.com都支持，但是c.class.com就不支持了，必须再买一个class.com，才会支持。（2）增强版和高级版增强型DV的基础是EV，EV会比DV安全性更好一点，企业级的SSL证书。EV的价格是最高的，如果要是银行企业就需要买EV的。（3）专业版如果是做银行金融，需要买更专业的OA版的。现在买免费版DV，免费版DV就只支持一个域名，不能再用到其他域名上。购买预支付不需要花钱就直接支付成功，然后直接确认支付。回到真实控制台，就能看到新购买的域名，之后需要跟域名做绑定。2、证书申请需要申请证书，然后要申请域名，比如现在申请的域名是www.yanyan.live，发现通配之后就直接写进来。申请人证书申请的时候有多种域名验证方式，有自动的DNS，有手工DNS验证和文件验证，一般常用的是前两个。在阿里云里面买的域名后台自动会帮做验证，如果域名不是在阿里云托管的，是在别的运营商，比如华为云等托管的，就需要手工DNS验证，这时需要一个解析，是tsp记录，然后那边做一下验证即可。SSL证书的生成方式，可以手动填写，也可以系统生成，一般默认是系统生成。下一步，提交之后手工验证，如果运营不在阿里云托管，就需要在托管商添加一条PSP解析，然后解析主机记录。下面有主机记录，记录值参加完之后点验证就可以。如果在阿里买就不需要做这个过程，直接验证，会自动在运营方做添加，验证成功了，回到域名看一下，在域名解析会自动添加一条 TXT记录。如果不在阿里云，需要手动添加一下，然后验证成功就可以提交审核，提交到ca公司。证书审核通过之后，可以看已签发在里面，就可以把证书下载下来，如果Tomcat就下载下来，下载之后传到服务器上。格式是ZipFiles，这就是我们证书文件，进去看一下是不是用的#docker exec -it WP bash，然后用的是一个阿帕奇，直接装在这个地方。一般配证书都是直接配到负载均衡那一层，在均衡层一般常用的是nginx，所以还是把它配到nginx顶层上。现在就一个域名，直接命名m.k，如果有多个域名多个帧数时，最好还是以域名的名字来命名，或者是有标志性的，需要配https，直接配到include里面。但是在confd里面可能会有多个文件，这种F配置文件，按拼音顺序读的。3、解析设置 yanyan.livenginx https，server_cyphers on，加了SSL的配置，刚才那个证书的名字是.pem。upstream yanyan _www {server 172.26.182.83 weight=5;}server {listen 443 ssl; server_name www.yanyan.live; ssl_certificate ssl/ssl.pem;ssl_certificate _key ssl/ssl.key; ssl_session timeout 5m;ssl_protocols TLSv1 TLSv1.1 TLSv1.2;ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:HIGH: aNULL : !MD5:!RC4 : !DHE;ssl_prefer_server_ciphers on;location/ {proxy_pass http://lyanyan www;}}样式没加载出来，如下图：像这种应该在代码里面内置的都是 HTTP，它都需要改成hdbs。现在相当于全站就都需 要 hdbs，访问 css 资源的时候也需要 hdbs，刚才已经分了，正好看一下效果。不分的话会有报错，主要是因为代码里面都写的是http，正常都需要写上 hdbs，没有配置 listen80的。代码需要修改，到时候需要做全代 hdbs，也不完全是运维的工作，开发也需要改。相当于直接改的是主链接，但是它内部有一些资源，比如 gs，cs 可能还有会有一些图片等等，这些的都需要改，如果不改还会再有一些问题，就是 hdbs 本来是 SDP 的时候会报错。
-
发表了文章 2022-11-17
Kubeadm 初始化流程简介及 dashboard v2.0.0-rc6部署 | 学习笔记
开发者学堂课程【Kubernetes 入门实战演练2020版：Kubeadm 初始化流程简介及 dashboard v2.0.0-rc6部署】学习笔记，与课程紧密连接，让用户快速学习知识。课程地址：https://developer.aliyun.com/learning/course/656/detail/10861Kubeadm 初始化流程简介及 dashboardv2.0.0-rc6部署内容介绍：一、初始化过程二、验证三、创建容量测试网络四、自托管五、部署 web 服务 dashboard一、初始化过程通过 kubernetes 的工具部署了一个三节点的高可用K8s集群，那么接下来 K8s 集群怎样去使用呢。目前为止还没有部署完，后面还有操作，我们把master节点和nodes节点加进来。这个情况就说明你的所有操作与调用都是没问题的。接下来我们通过kubeadminit看，这个时候应该做的步骤就是在GitHub上面会有个链接。这是早期的一个初始化过程，现在新版本也都一样，无论使用哪一个都很类似，这个页面是基于kubenetes1.9说的，跟新版本很类似，如果新版本的很笼统，在入门里面看，在官方文档里面，主页教程，看到这个会有一个安装的教程，搜索一下这个工具，在任务里面，安装工具，就有一个页面，然后包括集群管理，都有相关文档。接下来看初始化页面，我们进行初始化还是通过课表kubeadm命令进行初始化，找到使用kubeadm进行证书管理，跳转网站，访问外网比较慢。初始化证书还在下面，这个写的比较笼统，例如搭载高可用的kubeadm是怎样使用的，过程也都有，但是较笼统。初始化工作流kubeadminit通过执行以下步骤引导一个Kubemetesmaster节点：1、在进行更改之前，运行一系列检查以验证系统状态。一些检查只会触发警告，有些检查会被视为错误井会退出kubeadm直到问题得到解决或用户指定了--skip-preflight-checks。比如说交换机或者跳过orl。2、生成自签名的CA（或使用现有的CA、如果用户提供)为集群中的每个组件设置身份。如使用自定义证书中所述，如果用户在通过--cert-dir配置的目景中(默认为/etc/kubernetes/pki)提供了自己的CA证书和(或)密钥，则跳过此步骤。这个时候我们看一下，这时候初始化证书，到达什么地方，在/etc/kubernetes/pki里面就可以看到这时候给你生成的一堆证书，包括crt证书，etc证书，还有front-proxy证书。这些都是证书，kpi内部交互都是走证书，如果你听过手动器布置的话，那么要给每个组件都放置证书，包括kube-proxy，要分发各种证书，这是网络组件的，都有证书，自己做相对麻烦，这里有kubeadm的时候，这个证书的签发就可以自动完成，这里面有一个配置文件，叫做kuberlet.conf，这个就是kuberlet的文件，之前讲过nginx节点是不会访问etc的，这时候就需要kuberlet去把自己的一些运行状态，去etc里面写文，需要上报给kuberlets管理端。3、在/etc/kubernetes中为kubelet.controlel-manager和scheduler编写配置文件，让它们能够连接APIserver,每个文件都需要有自己的标识。同时还需要为管理用途编写名称为admin.conf的文件。例如congtrol-manager，这个就是一个配置文件，将会把kubelet的初始配置信息写入/var/lib/kubelet/config/init/kubelet/文件中，然后进行设置，当然现在已经不用了，这个功能可以进行忽略掉，这些新功能一般不用，另外如果没有提供外etcd，也会为etcd生成一个额外的静态Podmanifest文件。4、如果kubeadm的-feature-gates=DynamicKubeletConfig参数被启用，它将会把kubelet的初始配置信息写入/var/lib/kubelet/config/init/kubelet/文件中。参阅通过配置文件设置kubelet参数和在生活集群中重新配置节点kubelet获取更多关于Kubelet动态配置的信息。此功能现在默认处于禁用状态。因为它受featuregate控制，但预计在未来的版本中将成为默认功能。5、为Apiserver.controllermanager和scheduler生成静态Pod的manifest文件。如果没有提供外部etcd，也会为etcd生成一个额外的静态Podmanifest文件。静态Pod的manifest文件将会写入/etc/kubernetes/manifest；kubelet监控这个目录以在启动时判断是否生成Pod。一旦控制平面Pod启动并运行，kubeadminit将会继续运行。某些文件里面，然后基于这个文件把所有的都串联起来，所以说这些创建的文件会被容器所加载，比方说鉴定地址，etc服务器等等，这是其中之一，还有好几个。6、如果kubeadm的-feature-gates=DynamicKubeletConfig参数被启用，它将通过创建一个ConfigMap和一些RBAC规则来完成kubelet动态配置，这些规则让kubelet能够访问配置文件，并且更新节点以让Node.spec.configSource指向新创建的ConfigMap。此功能现在默认处于禁用状态因为它受featuregate控制，但预计在未来的版本中将成为默认功能。7、将标签和tant应用到master节点，这样就不会有额外的工作负载运行在该节点上。当你getnode你就会发现，master都是ready，这个角色roles也是显示master，然后我们可以手敲去进行，label··help，打标签，打完标签就进入了哪种功能。比如说亲和性和反亲和性都可以通过标签来实现。8、生成token以让额外的node能够将它们自己注册到这个master，可以默认指定token--help，这就是token的管理密令，然后创建，删除，生成，list，这也是测试的一个过程，还有一个叫做dry-run，跟这个很类似，只是用作测试运行。可以list一下token，看看现在有哪些，在过期前是可以使用的。过期就无法使用了，用不了就需要重新生成，dockerps节点加入后会启动一些文件，让这些容器运行起来，这个是bootstrap操作。9、创建所有必需的配置以让node能够通过Bootstap-Tokens和TLSBootstrap机制来加入集群。（1）编写一个ConfigMap来提供加入集群所需要的所有信息，并设置相关的RBAC访问规则；（2）让BotstrapToken能够访问CSR鉴权API；（3）为所有新的CSR请求配置auto-approval。进行一个授权，如果没有自动做的话，你通过kubectlcsr进行一个授权，就类似于证书签名生成一个csr文件，如果自动应答，就会为所有新的CSR请求配置auto-approval，这个有利也有弊。每一个都自动应答，这样安全性不高，为了安全性考虑，把权限控制好。10、安装内部的DNS服务，并且通过APIserver插件组件。请注意，就算部署了DNS服务，但是在安装CNI之前它也不会被调度到node上。这个DNS会在过程中显示，现在通过kubectlgetpod·A，查询所有的pod，现在看到的状态就是，都是running，都是运行的，然后alpha特性，一般不看。所以说每个Master上跑的服务都是一样的。11.如果在调用kubeadminit时先启用alpha特性self-hosting(--feature-gates=SelfHosting=ture)，那么基于静态Pod的控制平面将会转变为自托管控制面(self-hostedcntrolplane)。二、验证初始化完成后再来验证所有的master节点，在验证时需要用到参数get，主要适用于验证pod、node、service及其他对象资源是否正常。get参数形式(-o|--output)中的-o可以改变输出结果，可以使用json、yaml、wide的方式输出，但是通过json与yaml不方便观看，而wide显示出的结果详细清楚：想要查看service，输入kubectlgetservice，显示结果如图：想要查看详细信息，输入kubectlgetservice-owide，显示如图更加详细的信息输入kubectldescribeservice，此处的service是类型，可以是pod、node等，后面加要查看的对象名称，例如输入kubectldescribeservicekubernetes，显示结果如图可以看到目前将这三个管理端作为后端服务器，即一旦访问到这个service地址，该service就会转到三个宿主机的6443端口，然后由宿主机上的6443端口进行处理响应。以上集群就创建完成，node、pod都正常，node节点也添加成功（所有节点都是ready状态）三、创建容器测试网络之后我们来创建容器测试网络创建一些容器以跨主机的形式进行测试，输入kubectlrunnet-test1--image=alpine--replicas=3sleep360000，再来查看pod是否创建起来，输入kubectlgetpod还未创建完成，输入kubectlgetpod-owide发现ERRImagePull镜像拉取失败，来手动拉取：输入dockerpullalpine，可以配置镜像加速器进行加速：sudomkdir-p/etc/dockersudotee/etc/docker/daemon.json<<-’EOF’>{>“registry-mirrors”:[“https://9916wlow.mirror.aliyuncs.com”]>}>EOF{“registry-mirrors”:[“https://9916wlow.mirror.aliyuncs.com”}再输入sudosystemctldaemon-reloadsudosystemctlrestartdocker节点添加成功后需要到master验证，加速器配置完成后再输入dockerpullalpine，此处手动不使用托管。四、自托管关于托管的介绍可以在官网上查看：从1.8版本开始，您可以实验性地创建一个自托管Kubernetes控制平面。这表示关键的组件如APIserver、controllermanager和scheduler都将以DaemonSetpods方式运行，DaemonSetPod通过KubernetesAPI配置而不是通过Kubelet的静态文件配置。警告：自托管目前仍是alpha阶段，但有望在未来的版本中成为默认行为。要创建自托管的集群，请传递--feature-gates=SelfHosting=true参数到kubeadminit。警告:请参阅自托管的注意事项和局限性。1.8版本中的自托管有非常重大的局限性，特别是，如果没有人工干预，一个自托管的集群，无法在master节点重启后自动恢复，这些局限性有望在托管的alpha版本中会得解决，默认情况下，到自托管的控制平面的Pod需要依赖于从hostpath卷中载入的证书。除初始创建外，这些凭据不受kubeadm管理。您可以使用--feature-gates-StoreCertsInSecrets=true来从Secret中读取控制证书，不过这个方式仍然处于实验阶段。在kubeadm1.8版本中，控制平面中自托管的部分并不包含etcd，它仍然运行在一个静态pod中。最好所有的管理端都要在我们自己手里，因为你不知道托管管理什么东西，后期修改你都不知道，有些命令不支持，托管的时候很多参数无法配置。回到代码，查看下载完成，再来查看pod是否创建起来，输入kubectlgetpod发现显示结果处于Running状态，再来输入kubectlgetpod-owide可以看到pod运行在不同的宿主机上，现在要验证电脑启动了一个容器之后查看它是否可以访问别的容器以及你的容器是否可以访问外网。输入kubectlexec，可以进入任何服务器，想要进入第一个容器，输入kubectlexec-it-net-test1-5fcc69db59-f7rgfsh，进入后再输入ifconfig就可以看到不同的容器，然后在容器中ping上别的容器，例如输入ping10.10.5.3，该步骤非常重要，无论使用什么方式布置的kubernetes，如果容器不能跨主机创建，相当于不能使用。目前就是通过第一个节点上的容器去访问别的节点上的容器或者让容器可以相互访问。检验内网是互通的后检验外网，输入ping223.6.6.6，不通ping一下网关，输入ping172.31.7.254，结果出不去宿主机，检查一下。该容器是跑到node1节点上，查看node1节点的参数，输入sysctl-a|grepforward，发现ipv4.ip_forward打开，再来输入ifconfig，发现是因为pod的地址未改，flannel中的地址段与pod不一致，退出后输入cd，输入vimflannel.yml，可以看到此处地址是192，导致flannel的配置参数不正确，改为10.10.0.0/16，改完之后再来查看pod，输入vimkubeadm-init.yml，查看地址为10.10.0.0/16，再来执行命令kubectlapply-fflannel.ymlkubectlexec-itnet-test1-5fcc69db59-f7rgfsh结果还是不能访问，那就先删掉，然后再重新创建，输入kubectldelete-fflannel.yml，删除是需要去etc里面删除的，比较慢，删完之后再重新创建。kubectlapply-fflannel.yml创建完后等待pod状态跑起来kubectlgetpod-A跑起来后再进入到容器中去验证kubectlexec-itnet-test1-5fcc69db59-f7rgfshifconfigping172.31.7.254这个时候已经可以正常通过，在宿主机上通向网关，到达网关，就可以访问外网，此时再来输入ping223.6.6.6，通过后查看是否可以ping域名，是否可以请求外网的域名，需要看dns中是否有解析服务，输入cat/etc/resolv.conf结果得到nameserver192.168.0.10，再输入pingwww.baidu.com不能通过退出后查看输入llkubectlgetservicekubectlgetservice-A结果显示dns是192.168.0.10没问题，再来输入llkubectlgetpodkubectlgetpod-A可以看到coredns运行正常，再来查看输入vimkubeadm-init.yml该文件也没有问题，再进入到容器中，输入kubectlexec-itnet-test1-5fcc69db59-f7rgfshpingwww.baidu.com地址不对，需要将kubeadm转到kubedns上，手动管理将参数改正确ping192.168.0.10地址是通的，再来装一个命令，输入cat/etc/issueapkaddtelnetIfconfig尝试ping一个其他域名pingwww.sina.com成功，那么就是dns问题，输入vi/etc/resolv.conf先将dns临时改成阿里云的：nameserver223.6.6.6再来ping,输入pingwww.sina.com，发现在dns修改之后就通了，所以网络没有问题，那么dns怎么改呢？输入kubectlgetpodkubectlgetpod-A先进行删除，输入kubectldeletepodcoredns-7f9c544f75-4wljr-nkube-system，删除后再来删除第二个此处删除后都会进行重建，此外dns也被保存在etc中，数据不会丢失kubectldeletepodcoredns-7f9c544f75-q8fk9-nkube-system，再来输入kubectlgetpod-A会发现coredns又被重建，所以pod是删不掉的，再来进入pod中，输入kubectlexec-itnet-test1-5fcc69db59-f7rgfshpingwww.baidu.com发现删完重建后通过，再来尝试pingwww.aliyun.com也通过再来将dns改回去，输入vi/etc/resolv.conf将dns由阿里云的改为自己的，将nameserver改为192.168.0.10改回去，再来输入pingwww.aliyun.compingwww.jd.com发现都通过，再来退出换个网线，由第一个容器换到第三个容器中，输入kubectlgetpod-Akubectlexec-itnet-test1-5fcc69db59-vhctdshpingwww.baidu.com结果通过，再来换一个容器，输入kubectlexec-itnet-test1-5fcc69db59-m2p8vshpingwww.baidu,com结果通过虽然可以正常使用访问了，但是你并不知道公网解析给转到了哪里，DNS服务是可以指定去哪里转发的，但是现在我们不能配置，因为在创建时kubedns是自动装成的。那么我们如何指定让kubedns或者coredns解析的域名不去公网，这是根本不合理的。解析出来的域名还有PowerDNS还有公司内部的dns服务。内部的dns会解析数据库的域名或者harbor的域名，所以我们希望kubedns和coredns解析不了的域名可以转到powerdns，使用PowerDNS再返回公司内部的域名，如果PowerDNS解析不了的域名，再转去公网的域名，这样又不容易去处理了，但是也有解决方案不做讲解。之前出现过一个问题，当kubedns或者coredns解析域名时都直接被劫成公网地址，就是因为我们使用的是默认的dns，没有指向powerdns，所以域名解析出现了问题。经过修改后先指向powerdns，然后再指向公网，这个时候网络也就没问题了。刚刚出现的将dns删掉后重建就可以的问题可能是存在我们在初始化kubernets时没有在一定时间内把网络给部署好，也就是说网络有问题，因为网络是不能修改的，所以只能删除再进行部署，也就是相当于重启了，虽然说也可能是网络导致的问题，但是在部署过程中应该不会再碰到这种问题。百度上显示的原因对我们来说不适用，dnsmasq我们并没有，输入systemctlstatusdnsmasq找不到该服务，我们需要去安装，如果安装了可能存在问题，若没有安装不可能存在该问题。五、部署 web 服务 dashboard登录github，然后搜索dashboard，可以看到有release，Dashboard的最新版本就是v2.0.0-rc6，这个版本是可以兼容1.17的，这也是我们为什么要讲解1.17的原因之一，但是dashboard兼容性不太好，可以在官网上看到目前最新kubernetes版本的1.17完全支持的版本范围，而1.14、1.15、1.16在兼容性上由于kubernetesAPI版本之间的重大更改，某些功能在Dashboard中可能无法正常工作。rc5也只是支持1.17的版本,rc4也是，rc3也是，rc2只支持1.16，之前我们使用的版本是v1.10.1,这个版本可以支持1.8，1.9，1.10等多个版本，但是1.11、1.12中间的带值版本没有那种完全符合的，中间的几个版本就没有那种可以完全兼容的，但是也是部分可用，造成了一个尴尬的地步。那么如何安装rc6呢？需要先下载镜像，输入dockerpullkubernetesui/dashboard:v2.0.0-rc6下载完后进入到cd/usr/local/src/ll将yml文件放此处官方文件上的介绍比较简单，本机上已经修改好了配置传入，在官方基础上添加了配置nodeport，使用宿主机去访问端口30002。这在官网上没有。官网上是service，没有该服务，那么我们就没有办法访问。此处只能从本地进行访问，除非添加别的策略，所以我们先用最简单的方式从外网进行访问。这样就可以让公网从此处访问yml。除此外，还修改了镜像地址，如果官方镜像下载不下来，我们就可以使用本地镜像，服务是跑不起来的，我们最好使用国内的地址。或者将dashboard看作公司的一个服务，我们不能每次都从外网上去下载，所以我们需要通过更快的方式去下载该镜像。我们需要使用到harbor。我们在harbor上面创建一个项目，然后把镜像传上去，因为刚才已经下载完成，所以我们就先访问一下harbor，输入网址harbor.magedu.com，然后登录网站，创建好项目baseimages，设置成公开项目。然后在当前节点上把镜像传上去，然后进行配置，输入dockerimagesdockertagcdc71b5a8a0eharbor.magedu.com/baseimages/v2.0.0-rc6这样我们的镜像下载就比较快了，可以再来查看下版本，输入dockerimages发现版本就是v2.0.0-rc6，再来输入dockertagcdc71b5a8a0eharbor.magedu.com/baseimages/dashboard:v2.0.0-rc6改完后传上去，但是现在还不能上传，先来写host文件，输入dockerpushharbor.magedu.com/baseimages/dashboard:v2.0.0-rc6vim/etc/hosts在hosts文件中将地址指向172.31在172.31.3.101.master1中输入172.31.3.106magedu.com，写完hosts后进行登录，输入dockerd--help|grepins然后修改service文件，输入vim/lib/systemd/system/docker.service找到service后在execStart后添加--insecure-registryharbor.magedu.com，然后就可以进行重启那么我们怎么能让宿主机在节点自动拦截镜像呢？稍后进行配置。改完之后先将docker进行重启，输入systemctldaemon-reloadsystemctlrestartdocker重启让配置进行生效，只有node节点会经常上传下载镜像，所以只需要配置node节点，master节点不需要进行配置，所以只有node节点需要添加该参数及解析，输入vim/lib/systemd/system/docker.service找到service后如上添加--insecure-registryharbor.magedu.com添加完后输入systemctldaemon-reloadsystemctlrestartdocker再输入dockerpullalpinevim/lib/systemd/system/docker.service进入后进行配置然后重启systemctldaemon-reloadsystemctlrestartdocker因为我们不知道容器会创建在哪个节点上，所以我们需要将三个节点都进行配置。重启后在管理端master上进行登录，输入dockerloginharbor.magedu.com不能登录发现域名出现问题，改为harbor.linux39.com，将上述的域名都改为harbor.linux39.com，改完域名后进行重启。将所有域名都修改，输入dockertagcdc71b5a8a0eharbor.linux39.com/baseimages/bashboard:v2.0.0-rc6登陆成功后输入Dockerpushharbor.linux.com/baseimages/dashboard:v2.0.0-rc6传上去后就可以将dashboard跑起来，现在跑不起来是因为宿主机像需要在外网上下载，如果宿主机下载不了镜像，那么该服务就不能跑起来。所以我们还是需要从内部下载，输入vim/lib/systemd/system/docker.service修改配置中的insecure-registryharbor.magedu.com为insecure-registryharbor.linux39.com，修改完后将docker重启，每个节点的配置中的service都需要进行修改。修改完后输入Systemctldaemoon-reload&&systemctlrestartdocker进行重启，三个节点都修改完后就可以让dashboard跑起来。那么如何跑呢？首先我的像已经上传了然后复制该镜像的地址，然后尝试看是否能够在node节点上将镜像拉取下来，输入Vim/etc/hostnameVim/etc/hosts进入后添加配置172.31.3.106harbor.linux39.com加上一个地址的解析，加上后再来尝试是否可以拉取镜像，需要先手动测试通过，输入dockerpullharbor.linux39.com/baseimages/dashboard:v2.0.0-rc6成功后就可以自动拉取镜像。将三个节点都配置上地址解析然后手动测试，完成后再来跑dashboard，在master中输入vimdashboard-2.0.0-rc6.yml再跑之前将镜像地址修改不去官网上下载，而是内网地址，修改地址将image修改完后，就可以进行创建。还用到一个镜像也进行修改，复制该地址另外一个窗口进行pull，输入dockerpullkubernetesui/metrics-scraper:v1..0.3下载完成后使用tag将地址进行修改，输入Dockertagdocker.io/kubernetesui/metrics-scraper:v1.0.3harbor.linux39.com/baseimages/metrics-scraper:v1.0.3改完后进行pull，输入dockerpullharbor.linux39.com/baseimages/metrics-scraper:v1.0.3然后将yml文件中也进行修改，修改为harbor.linux39.com/baseimages/metrics-scraper:v1.0.3让node节点到我们自己的节点上下载镜像此外还添加了一个yml,admin-user.yml，用来进行权限控制，再来输入Kubectlapply-fdashboard-2.0.0-rc6.ymlKubectlapply-fadmin-user.yml创建完两个文件后输入KubectlgetpodKubectlgetpod-A可以看到由于内部下载，镜像下载非常快，pod访问也快再使用kubectlgetservice进行访问输入kubetclgetservice-A结果显示端口中有30002，此时我们就可以进行访问，在官网上输入172.31.6.108:30002107、108、109节点都可以，因为node比较特殊，一旦定义了port在任何一个节点上都会进行监听，那么30002意味着当前我们是三个节点，那么三个node节点都监听，可以进行验证，比如在107上输入ss-tnl结果如下可以看到结果中存在30002，按照此方法验证108和109访问结果存在服务协议问题，输入网址https://172.31.3.108再进行回车就可以进行访问了。此时又存在问题需要使用临时的token进行登陆，那么怎么获取登录token呢？在管理端输入kubectlgetsecret-Algrepadmin-user.kubernetes-dashboardadmin-user-token-6kwbrkubernetes.io/service-account-token33m15skubectldescribesecretadmin-user-token-6kwbr-nkubernetes-dashboard这样就可以拿到token将token复制后输入到刚才网页上发现可以登录这样就可以使用dashboard了，以上就先将dashboard跑起来。左侧菜单可以切换namespaces，namesoacs是集合项目的，我们会将每个项目的namespaces跑在每个项目中，所以想要查看哪个项目的namespaces就可以进行切换，默认是default。如果想要到pod中去查看有哪些东西，就可以选择其中的pod然后进入到pod中去进行操作。所以master或者pod权限非常多，我们要注意不能泄露。
-
发表了文章 2022-11-17
阿里云 RDB（2）｜学习笔记
开发者学堂课程【阿里云新手上云实战演练：阿里云 RDB】学习笔记，与课程紧密联系，让用户快速学习知识。 课程地址：https://developer.aliyun.com/learning/course/655/detail/10852阿里云 RDB二、建站回答第一个实验，先做简单的建站一条龙，把 HTTP 网站做成 https，首先是了解一下步骤，运维和环境可能更多的需要，因为开发来做代码。1、购买域名注意点如果您申请注册的域名存在以下情形，该域名将处于“不可注册"状态:（1）工信部备案中心黑名单库中的域名，域名前缀内容违反《互联网域名管理办法》第二十八条第(八)项规定的内容，例如涉及到政党、伟人名字、暴力、违禁药品、色情等内容。（2）涉及诉讼、仲裁、处罚等的域名。（3）注册局设置的特殊保留域名。（4）按照政策规定不可注册的其他敏感词汇域名，自定义域名前缀时请关注域名的命名规范。命名规范可参考域名命名规则章节。2、备案注意点根据政策规定，解析至中国大陆境内服务器的网站等服务，必须完成备案才可对外提供服务。（1）如果您没有提交过备案，直接将域名解析至阿里云中国大陆境内服务器上，将被阿里云监测系统识别并阻断网站服务，提示您需先完成备案。（2）如果您已经在其他接入商处申请过备案，现在希望将域名解析至阿里云中国大陆境内服务器上，根据政策要求，您需要将备案信息接入阿里云。如果您没有将备案信息接入阿里云，将被阿里云监测系统识别并阻断网站服务，提示您需要将备案信息接入阿里云。3、使用云服务器ECS有下列限制（1）不支持虚拟化软件安装和再进行虚拟化(例如安装使用VMware Workstation)。目前仅弹性裸金属服务器和超级计算集群支持再虚拟化。（2）不支持声卡应用。（3）不支持直接加载外接硬件设备（如硬件加密狗、U盘、外接硬盘、银行U key等），您可以尝试软件加密狗或者动态口令二次验证等。（4）不支持SNAT等IP包地址转换服务。您可以使用自己搭建VPN或者代理方式来实现。（5）不支持多播协议。如果需要使用多播，建议改为使用单播点对点方式。（6）日志服务不支持32位Linux云服务器。您可以参见服务入口查看支持日志服务的地域(Region);参见使用logtail采集日志概述查看支持日志服务的云服务器系统。 三、阿里云 RDS下面看一下如何购买阿里云的服务器。1、MySQL版本实例阿里云关系型数据库(Relational Database Service，简称RDS)是一种稳定可靠、可弹性伸缩的在线数据库服务。基于阿里云分布式文件系统和SSD盘高性能存储，RDS文持MySQL、SQL Server、PostgreSQL、PPAS ( Postgre Plus Aavanced server，高度兼容Oracle数据库）和MariaDB TX引擎，并且提供了容灾、备份、恢复、监控、迁移等方面的全套解决方案，彻底解决数据库运维的烦恼。比如有好几个T的数据，自己做这个过程就特别麻烦，中间可能会有中断，但是阿里云提供了一个数据传输的服务，直接选择原库，选择目标库，然后帮做这个数据的同步，包括增量，也可以帮做增量的同步。如果要做数据库迁移的时候，可以使用这个数据服务。 2、RDS 使用步骤只要是这种服务器服务基本都是这个步骤，比如在阿里云买Kafka等，只要提供的这种资源都可以买，创建一下设置一下白名单，然后配一个公网地址。配公网地址的时候，一般申请就行了，会生成一个公网地址，数据库相当于前三步有一个数据库实例，第四步就是创建数据库，再创建一个子账号，直接创建的时候可以不让它接受对某个数据库授权的账号，只不过阿里云全部把这个过程放到了外部界面上，通过UI的方式直接实现了，然后连接跟使用数据库。 四、使用 RDS 做 WordPress 数据库绩效内置是可以装数据库的，不想用自己创建的数据库，想用阿里云上的数据库，现在就需要做实验二：在实验一的基础上使用RDS来做work press数据库。RDS管理控制台：现在先创建 RDS 实例，选择按量付费，其他配置如下图：然后下一步。刚开始买 ECS 的时候有一个默认的交换机，这样如果不在创建都是默认的。交换机也是默认，资源组是做资源隔离的。确认订单，这样就购买成功了，要比买ecs 简单。1、推荐数据库阿里云新的数据库是更强大的数据库，如果数据量一般，推荐大家用RDS，假如数据库如果上了T级别，推荐大家可以用云数据库POLARDB，相当于直接买完就是一个RDS实例，买完就是一个数据库集群，这个性能会更高，但是这个价格也比较贵。2、产品优势（1）简单易用POLARDB兼容多款流行的关系型数据库引擎，完全兼容MySQLUPostgresQL，高度兼容Oracle语法，代码/应用无需修改或只需少量修改。（2）降低成本计算节点和存储分离:多个计算节点共享存储，新增只读节点时只需支付计算节点费用，大大降低扩容成本。Serverless存储:存储空间无需手动配置，根据数据量自动伸缩，您只需为实际使用的数据库容量付费。（3）极致性能深度优化数据库内核，同时采用物理复制、RDMA高速网络和分布式共享存储，大幅提高性能。集群包含一个主节点和最多15个只读节点，满足高并发场景对性能的要求，尤其适用于读多写少的场景。基于共享存储的一写多读集群，数据只需要一次修改，所有节点立即生效。 （4）海量存储,支持上百TB级别数据采用分布式块存储设计和文件系统，使得存储容量不限制于单节点的规格，能够轻松扩展，应对上百TB级别的数据规模。如果申请一个外网地址，运行中才能申请看实际状态不支持，该操作运行中才能申请，最好是别申请外网地址，数据库不需要对外访问。 基本信息：可以申请公网IP，可以设置白名单，设置了白名单之后就白名单可以访问，剩下都不能访问。账号管理实际在运行中可以创建账号，现在没在运行中，所以不能创建。备份恢复，可以设置定期备份，备份、设置、编辑，可以设置定期备份。安全性就是白名单，在基本信息可以设置白名单，在数据安全性也可以设置白名单。参加白名单分组或者可以直接在默认分组，在默认分组时只有自己能连，需要连这台数据库的内网地址写进去。3、参数设置这里有一些是改了直接生效，有一些改了需要重启数据库。
-
发表了文章 2022-11-17
Kubeadm 初始化高可用 kubernetes v1.17.2集群 | 学习笔记
开发者学堂课程【Kubernetes 入门实战演练2020版：Kubeadm 初始化高可用 kubernetes v1.17.2集群】学习笔记，与课程紧密连接，让用户快速学习知识。课程地址：https://developer.aliyun.com/learning/course/656/detail/10860Kubeadm 初始化高可用 kubernetes v1.17.2集群内容介绍：一、Kubeadm二、初始化设置一、KubeadmKubeam 如何基础化集群，文档可以查看官方文档。Kubeadm参数有很多，其中主要的一些都添加了注释，所以除了可以查看官方文档外，还可以查看老师写的文档，其中都添加了注释。1.Kubeadm是一个工具，它提供了Kubeam init 以及 Kubeam join这两个命令，Kubeam init 是一个初始化的集群，join是将一个mast节点护着nobe节点加入到Kubermnetes中去，作为快速创建kubernetes集群的最佳实践。ubeadm 通过执行必要的操作来后动和运行一个最小可用的集群。其中必要的操作有很多，包括各种镜像，各种证书和内部的集群。它被故意设计为只关心启动集群，而不是准备节点环境的工作，也就是参数的初始化以及调优和各种命令，都得自己进行。同样的，诸如安装各种各样的可有可无的插件，例如Kubermnetes 控制面板、监控解决方案以及特定云提供商的插件，尤其是国外的几个特定云与kbs的兼容性相对比较好，会有特殊的接口协议，比如存储的时候，一些接口可以直接到kbs上，让kbs可以被调用；但是国内一些软件的支持就不太好，阿里的支持性也不太好。可以自己选择版本，包括1.16，1.17等。这些都不在它负责的范围。相反，我们期望由一个基于kubeadm 从更高层设计的更加合适的工具来做这些事情;并且，理想情况下，使用kubeadm作为所有部署的基础将会使得创建一个符合期望的集群变得容易。2、使用帮助：kubeadm init启动一个 Kubernetes主节点kubeadm join启动一个 Kubernetes工作节点并且将其加入到集群kubeadm upgrade更新一个Kubernetes集群到新版本kubeadm conig 如果你使用kubeadm v1.7.x或者更低版本，你需要对你的集群做一些配置以便使用kubeadm upgrade命令kubeadm token使用kubeadm join来管理令牌kubeadm reset还原之前使用kubeadm init 或者kubeadm join对节点产生的改变kubeadm version打印出 kubeadm 版本kubeadm alpha预览一组可用的新功能以便从社区搜集反馈主要查看kubeadm init。点击进入，进入之后右上角可以选语言，选择中文。kubeadm init此命令初始化一个 Kubernetes 控制平面节点，也就是控制端。概要：运行此命令来搭建Kubernetes控制平面节点。*init”命令执行以下阶段:root@kubeadm-master1:~# kubeadm init –help 查看参数2.-apiserver-adwertise-address stringAPI服务器所公布的其正在监听的IP地址。如果未没置。则使用默认网络接口.--apiserver-adivertise-address string --apiserver-bind-port int32 接听端口有很多类型，有字符串类型也有数字类型。有这样要求的原因在于，后期调用的时候，有的是用API调用的。API调用的时候就需要传递相应的数据类型，如果要求的调用的是字符串，而错误传递数字就有可能调用不成功。这是API的要求，假如是初始化则无所谓。②--apiserverbindport int32 Port for the API Server to bind to. (default 6443)--apiserver-cert-extra-sans strings Optional extra Subject Alternative Names (SAVs) to use for the API Server serving certificate. can be both IP addresses and DNS#可选的证书额外信息，用于指定API server的服务器证书。也可以是IP地址也可以是dns名称。是可选的，凡是跟证书有关的配置，都不需要配置，因为它会自动初始化，在老师文档中字体颜色为紫色的是需要指定的。黑色的都不要指定的，红色的是在左kds调节时使用。假如kds需要装一个负载均衡的节点，需要基于这个节点来使用。③--cert-dir string#证书的存储路径，缺省路径为/etc/kubernetes/pki④--certificate-key string#定义一个用于加密kubeadm-certs secret中的控制平台证书的密钥.③和④都不需要定义。4.--config string #kubeadm #配置文件的路径 保持默认。二、初始化设置1、Config 文件的位置当前用户的加目录会生成一个config文件，这个config文件是后期加命令连接apiserve的重要凭据。其他配置文件。例如会通过一些容器来启用一些控制端容器，这些容器也有配置文件，就保持默认就可以。-config string path to kubeadm configuration file2、-control-plane -endpoint string#为控制平台指定一个稳定的IP地址或DNS名称，即配置一个可以长期使用切是高可用的VIP或者域名，k8s 多 master高可用基于此参数实现.Specify a stable IP address or DNS name for the control plane这个控制平台可以认为是api的控制加端口。就是访问kbs的时候需要通过ip加地址的方式。虽然可以用域名进行解析，但最后都会被解析成一个ip地址。你通过那个地址跟哪个端口来访问kds客户端。apiserver-adwertise-address string是客户端的监听地址。监听地址是本机的，需要写成本机的或者0-0-0来监听本地的所有地址，假如更换服务器3.103，就需要更写3.103. 但是—control -plane-endpoint string 这个地址是不需要更改的，作用是稳定地址或者控制域名给你的控制平台。但这个域名就是hperson 和keplove所监听的地址。如下图所示，配置一个稳定的地址：172.31.3.102，这个地址就是稳定的地址不会更改，不像服务器的地址，而且服务器还存在多个，所以如何对kpr的多个服务器进行统一的调度和访问呢。解决办法就是通过wep对他们进行负载平衡。所以最终访问的时候访问的是终止平台端口的6443，当然这个过程是由kepha-l来保证高可用，kep来保证端口的可用性。会让请求这些ha-l的地址往mater上分发。以tcp的方式。如何进行配置。kubeadm init -- api serve r adve rtise- address-172.31.3.101 --apiserver bind- port=6443 -- control-plane endpoint=172.31.3.248 所以会用3.248作为kube master对外的一个入口。3、- cri-socket string #要连接的CRI(容特运行时接口，Container Runtime Interface, 简称CRI)套接字的路径，如果为空，则kubeadm将尝试自动检测此值，"仅当安装了多个CRI或具有非标准CRI插槽时，才使用此选项"。这个也不用配置，因为最后也会保持默认。4、-dry-run #不要应用任何更改，只是输出将要执行的操作，其实就是测试运行。Don’t apply any changes;just output what would be done 5、- experimental kustomie string #用于存储kustomize为静态pod清单所提供的补丁的路径。不需要配置。6、-feature gates string#-一组用来描述各种功能特性的键值(key=value) 对，比如说一些类似于arf功能，或者一些很特殊的功能。选项是: IPv6DualStack=true|false (ALPHA - default=false)7、ignore preflight errors strings #可以忽略检查过程中出现的错误信息，比如忽略swap, 如果为all 就忽略所有。在系统进行初始化的时候会对系统进行各种检查，包括内核参数，交换分区是否符合安装分发所要求，如果不符合要求就会报错，甚至会直接停止安装或者继续进行初始化。其实有些totle是可以忽略的，比如交换分区，就就想用交换分区，可以提供某些参数，把检查忽略掉。例如：ignore-preflight-errors=swap这是只忽略其中一个选项，如果想忽略所有检查，“value all”ignores errors from all.交换分区可以用，但会降低性能，所以最好不要用。忽略交换分区的检查报错。ignore-preflight-errors=swap8、--image-repositorystring 一定要写。客户端adm在初始化kidemaster时，会需要一些径向，这些径向就是所需要的三个服务的径向。径向默认到Choose a container registry to pull control plane images from (default "k8s.gcr . jo" )。但这个地方是谷歌的径向仓库，根本下不来。所以会将其指向国内的一些径向网站，比如阿里云等。Registry.cn-hangzhou.aliyuncs.com/gogle_containers/coredns：1.6.5就是阿里云谷歌的径向仓库，会将谷歌的径向仓库下载到阿里云的径向仓库，之后就可以从阿里云上下载，这样再下载径向就不会报错。9、-kubernetes- versionstring #指定安装k8s版本，默认为stable-1. Choose a specific Kubernetes version for the control plane. (default " stable-1")一般情况下都需要手动指定，假如想装1.17.2，-kubernetes- versionstring=1.17.210、--node name string#指定node节点名称。这个一般不需要指认。Master节点或者novel节点加到kebmaster之后，使用kebmaster的某些命令，查看kebmaster中的novel节点，那么如何区分哪些是novel节点呢，可以通过主机名进行区分，可以在kebmater中保证主机名是唯一的。11、-pod-network-cidr #设置pod ip地址范围，这个一定要设置，也就是设置给你的容器一个ip地址段，这个ip地址段可以自定义，前提是后期的网络插件，有些网络组件是可以指定ip地址段的，在网络插件中，地址跟这个一致。K8s里面有三个地址段，那么容器分哪个地址段呢，只需要跟当前网络不冲突就行。如果在多系统条件下，也得保证容器地址段跟任何一个网络都不冲突，否则后期在跨机房调用时，就会出现ip地址没法调用，因为出现重复，网络地址就没办法指用，在后期多机房的情况下，一定要划分清楚，避免出现重复。-pod-network-cidr=10.10.0.0/165划分成了一个16的字符页面，IP字段是10.10.的。12、-service- cidr #设置service网络地址范围。Service的地址段也需要进行指定。存在默认值，在这两个网络中，service的地址应用很少，一个业务有二三十个服务，就算一个服务占用一个service地址，也有很多地址。Pod则不同，所以这个网段消耗比较大-service- cidr=192.168,这样好区分。13、-service -dns -domain string #设置k8s内部域名，默认为cluster.local, 会有相应的DNS服务(kube- dns/coredns)解析生成的域名记录。这些值也都需要设置，一般会修改后缀，例如可以改成-service -dns -domain=Linux39.local 这个local只是一个序列，也可也改成nate等。后期会创建Linux39.local，创建的service会由kbds等来解析成记录。14、--skip-certificate-key-print#不打印用于加密的key 信息--skip-phases strings #要跳过哪些阶段,--skip-token-print#跳过打印跳过一些检查。一般需要进行打印，因为不打印不知道towken是什么信息，跳过的话就无法将note节点和master节点加入进来，这个过程是需要使用token的，所以不需要跳过，需要打印出来。15、--token string The token to use for establishing bidirectional trust between nodes and control-plane nodes. The format is [a-z0-9](6).[0-20- ]{16j - e.g. abcdef.0123456789abcdef 可以给客户adm传递一个参数，给参数设置一个固定的token，这个值给了一个固定的格式，格式就是[a-z0-9](6).[0-20- ]{16j - e.g. abcdef.0123456789abcdef不需要更改，默认会给一个初始化的token。16、--token-ttl duration The duration before the token is automatically deleted (e.g.1s， 2m，3h). If set to '0 '， the token will never expire (default 4h0m0s) 意思是 无论用户设置的token还是系统默认的token都会有一个默认的生命周期，生命周期默认值是24小时，一天之后就会过期。如果想将token的默认周期设置更长，可以进行更改。可以设置多少小时，多少分，多少秒；假如想设置三天，则可以更改成72小时。但是token值不要设置太长，因为万一流传出去，别人就会使用token值来管理kbs,所以一般不需要更改，保持默认就可以。17、--upload-certs Upload control-plane certificates to the kubeadm-certs Secret. 作用是更新ksb证书，不需要更改，证书它会自动进行更新。18、#全局可选项:-add-dir-header #如果为true，在日志头部添加日志目录。不需要添加，添加了之后会在头部添加一个日志目录。--log-file string #如果不为空，将使用此日志文件·不需要添加，一般更新在系统日志里。--log-file-max-size uint #设置日志文件的最大大小，单位为兆，默认为1800兆，0为没有限制--rootfs #宿主机的根路径，也就是绝对路径。不需要设置--skip-headers#如果为 true，在log日志里面不显示标题前缀不需要设置，将日志打印成标准日志就可以--skip-log-headers#如果为 true，在 log日志里里不显示标题。不需要设置，将日志打印成标准日志就可以。所以最终进行初始化所写的选项就是以下内容，这些内容就足够进行初始化了。kiteadm init --apiserver-aivertise-address=172.31.3.101 --apiserver-bind-port=6443 --control-plane-endbointal172.31.3.248--ignore-preflight-errors=Swap --image-repository=registry .on-hangzhou.aliyuncs .com/google containers/-kubernetes-version=v1.17.2 --pod-network-cidr=10.10.0.0/16--service-cidr=192.168.1.0/20--service-dns-domain=linux39.local2、镜像的准备2.1了解下载什么镜像root@kubeadm-master1:~#kubeadmversionkibeadm version: bversion. nfo(rajor '"1 , kinor "17'，, itersion."v1.7.2 ， 6itcamnt 583ce5o3c87158e510657的9f242K64df89',6itieste;'clea ', Bbildnate:'2021-01-18T23:27:49z"，GoVersion: "go1.13.5，Compiler: "gc""Platform: "linux/amd64"}root@kubeadm-master1:~#.本机系统版本是v1.17.2，所以需要下载17.2的镜像。此镜像需要去谷歌的镜像仓库去下载。#查看安装指定版本k8s需要的镜像有哪些,# kubeadm config images list --kubernetes-version v1.17.3-k8s.gcr.io/kube-apiserver:v1.17.3k8s.gcr.io/kube-controller-manager:v1.17.3-k8s.gcr.io/kube-scheduler:v1.17.3k8s.gcr.io/kube-proxy:v1.17.3k8s.gcr.io/pause:3.1-k8s.gcr.io/etcd:3.4.3-Ok8s.gcr.io/coredns:1.6.5# kubeadm config images list --kubernetes-version v1.17.3-会将用户所设置的镜像打印下来，就得到了一个镜像的列表。k8s.gcr.io/ kube-apiserver:v1.17.2k8s.gcr.io/ kube-controller-manager: v1.17.2k8s.gcr.io/ kube-scheduler: v1.17.2k8s.gcr.io/ kube-proxy : v1.17.2k8s.gcr.io/pause:3.1k8s.gcr.io/etcd:3.4.3-0k8s.gcr.io/coredns : 1.6.5root@kubeadm-master1:~#会告诉用户所需要的镜像是多少，apiserver所用到的镜像是1.17.2；controller-manager所用到的镜像是1.17.2，scheduler所用到的镜像是1.17.2。Pause意思是在一个Pause中封装一个网络接口，就是基于Pause这个镜像进行封装的。给每一个point封装一个底层的网络，目前所使用的版本是3.1,而且版本更新很慢。让这个point中多个容器公用一个基层的网络信息，网络是公用的，但系统是隔离的。镜像下载，已经知道了镜像和阿里云镜像地址，镜像可以直接进行安装，下载的时候可以直接进行初始化。也可以手动将镜像先下载下来，这样在初始化时所用的时间就会比较短。registry.cn-hangzhou.aliyuncs.com/google_containers/k8s.gcr.io/ kube-apiserver:v1.17.2k8s.gcr.io/ kube-controller-manager:v1.17.272 k8s.gcr.io/ kube-scheduler:v1.17.2k8s.gcr.io/pause:3.1K8s.gcr.io/etcd: 3.4.3-oK8s.gcr.io/coredns:1.6.5然后将域名更换成阿里云的域名，docker pull registry.cn-hangzhou.aliyuncs. com/google_containers/kube-apiserver:v1.17.2docker pull registry.cn-hangzhou.aliyuncs.com/google_containers/kube-proxy:v1.17.2docker pull registry.cn-hangzhou.aliyuncs.com/google_containers/pause:3.1docker pull registry.cn- hangzhou.aliyuncs.com/google_containers//etcd:3.4.3-Odocker pull registry.cn-hangzhou.aliyuncs.com/google_containers/coredns:1.6.575为了节省时间，直接下载下来，因为初始化有时间限制，一旦超时就下载失败了。复制下载命令的镜像：rooti@kubeadm-master1:m# docker pull registry.cn-hangzhou .aliyuncs.com/google_containers/kube-apiserver:v1.17.2registry.cn-hangzhou.aliyuncs.com/google_containers//etcd:3.4.3-0docker pull registry.cn-hangzhou.aliyuncs.com/google_containers/coredns:1.6.5v1.17.2: Pulling from google_containers/kube-apiserver597de8ba0c30: Downloading [>]213kB/21.09MB46657ede464b: Pulling fs layer让去阿里云下载就可以。最终会得到五个镜像，下载完进行验证，发现少了contreller manage 的镜像，是因为少复制了。但是没关系，因为可以自动进行下载。然后将其复制过来也进行下载。docker pull registry.cn-hangzhou.aliyuncs.com/google_containers/contreller manage:1.7.2下载完成之后就可以进行初始化了。70docker pull registry.cn-hangzhou.aliyuncs.com/google_containers/etcd:3.4.3-071然后将etcd也复制进去，就可以进行初始化了。初始化有两种方式，一种是Kubeadm传参的方式，另一种是配置文件，可以生成一个config文件来进行初始化。这些服务，只需要提供参数就可以，然后他会自动生成文件，传递参数。See 'snap info ' for additional versions.root@kubeadm-master1:~#dco im^croot@kubeadm-master1:~#docker imagesREPOSITORY查看镜像是否正确root@kubeadm-master1:~# kubeadm config images list --kubernetes-version v1.17.2w 327 14:34:07.14126527949 validation.go:28]Cannot validate kube-proxy config · no validator is availableW0327 14:34:07.14131127949 validation.go:28]Cannot validate kubelet config -no validator is availablek8s.gcr.io/ kube-apiserver: v1.17.2k8s.gcr.io/ kube-controller-manager: v1.17.2k8s.gcr.io/ kube-scheduler: v1.17.2k8s.gcr.io/ kube-proxy : v1.17.2k8s.gcr.io/pause:3.1k8s.gcr.io/etcd:3.4.3-0k8s.gcr.io/coredns : 1.6.5root@kubeadm-master1:~#少了一个镜像k8s.gcr.io/ kube-proxy : v1.17.2这两种方式都可以，假如想安装的话可以反反复复多次安装，可以先安装，然后进行多次尝试。root@kubeadm-master1:~# docker pull registry.cn-hangzhou.aliyuncs.com/google_containers/kube-proxy.v1.17.2v1.17.2: Pulling from google_containers/ kube-proxyDigest: sha256:4a1b15c88bcfb832de4d3b8e7f59c8249007554174e3e345897bcad4e7537fafStatus: Image is up to date for registry.cn-hangzhou.aliyuncs.com/google_containers/kube-proxy:v1.17.2registry.cn-hangzhou.aliyuncs.com/google_containers/kube-proxy:v1.i7.2root@kubeadm-master1:~#docker imagesREPOSITORYregistry.cn-hangzhou.aliyuncs.com/google_containers/kube-proxy TAG IMAGE ID CREATED SIZEregistry.cn-hangzhou.aliyuncs.com/aooale containers/kube-prixyregistry.cn-hangzhou.aliyuncs.com/google_containers/kupe-ap1serverregistry.cn-hangzhou.aliyuncs.com/google_containers/corednsregistry.cn-hangzhou.aliyuncs.com/google_containers/etcdregistry.cn-hangzhou.aliyuncs.com/google_containers/pauseroot@kubeadm-master1:~#root@kubeadm-master1:~# kubeadm config images list --kubernetes-version v1.17.2W0327 14:35:36.74930628300 validation.go:28] Cannot validate kube-proxy config - no validator is availableM0327 14:35:36.74933928300 validation.go:28] Cannot validate kubelet config -no validator is availablek8s.gcr.io/ kube-apiserver: v1.17.2k8s.gcr.io/ kube-controller-manager: v1.17.2k8s.gcr.io/ kube-scheduler: v1.17.2 k8s.gcr.io/ kube-proxy: v1.17.2k8s.gcr.io/pause:3.1k8s.gcr.io/etcd:3.4.30k8s.gcr.io/coredns:1.6.5root@kubeadm-master1 :~#.少了一个kube，应该是复制的时候不小心删除了将它下载下来。docker pull registry.cn-hangzhou.aliyuncs .com/google_containers/kube-controller-manager:v1.17.2复制schedularroot(kubeadm-master1: # docker pull registry.cn-hangzhou.aliyuncs.com/google_containers/kube-scheduler:v1.17.2 此时7个镜像就足够了，有两种方式可以进行安装。3、初始化的两种方式第一种方式：单节点master初始化: # kubeadm init--apiserver-advertise-address=192.168.7.101 --apiserver-bind-port=6443kubernetes-version=v1.17.3 --pod-network-cidr=10.10.0.0/16 --service-cidr=10.20.0.0/16--service-dns-domain=linux36.local --image-repository=registry.cn-hangzhou.aliyuncs.com/google_containers --ignore-preflight-errors=swap下载完kubeadm,使用kubeadm的方式传递参数第二种方式，使用kubdeam生成初始化文件，然后再对问文件进行修改，基于文件初始化高可用master方式: .# kubeadm config print init-defaults #输出默认初始化配置, # kubeadm config print init-defaults > kubeadm-init.ml #将默认配置输出至文件.# cat kubeadm-init.yaml#修改后的初始化文件内容.这种方式包括接口，token，controllerplaneendpoint 等，镜像地址，版本，域名，ds后缀等等。apiVersion: kubeadm.k8s.io/v1beta2bootstrapTokens:-- groups:-- system:bootstrappers:kubeadm:default-node-token-token: abcdef.0123456789abcdef.ttl: 24h0mos-- signing- authentication-kind: InitConfiguration-localAPIEndpoint:-advertiseAddress: 172.31.3.101.nodeRegistration:-criSocket:/var/run/dockershim.sockname: k8s-master1.magedu.nettaints:-- effect: NoSchedule.key: node-role.kubernetes.io/master-apiServer:-timeoutForControlPlane: 4mOsapiversion: kubeadm.k8s.io/v1beta2certificatesDir: /etc/kubernetes/pki-clusterName:KubernetescontrolPlaneEndpoint: 172.31.7.248:6443#添加基于VIP的 EndpointcontrollerManager:dns:type: CoreDNS.etcd:local:-dataDir: /var/lib/etcdimageRepository: registry.cn-hangzhou.aliyuncs.com/google_containerskind: ClusterConfiguration-kubernetesVersion: v1.17.3networking:dnsDomain: magedu.localpodSubnet: 10.10.0.0/16.serviceSubnet: 172.26.0.0/16scheduler:{}单节点地址就直接指定初始化，多节点稍微复杂点。高可用则需要指定master方式。高可用master初始化: 首先基于keepalived实现高可用vIP，然后实现三台 k8s master基于VIP实现高可用。·基于命令初始化高可用master 方式:#kubeadm init --apiserver-advertise-address=172.31.3.101 --control-plane- endpoint=172.31.7.248 --apiserver-bind-port=6443 --kubernetes-version=v1.17.3 --pod- image-repository=registry.cn-hangzhou.aliyuncs.com/google_containers --ignore-preflight- errors=swap通过命令进行初始化：直接进行初始化，假如·有·命令·可以反反复复进行初始化，没有镜像也没关系，系统会自动提供。这个过程可能需要一段时间，需要稍微等待一下。root@kubeadm-master1:~#docker images^crotitsto pn-masterl -4 itbah init ..apisever-adertis-tbres=172.313.121 .apiserv r-bind-part-5f43 .-control-plane-endpoint=172.31.3.248 ..ignore-preflight-errors5%的imnage-rpsitorjeregistry can-hanghou.atiyunc .cao goole cantainers/ ..hivemetes-version=v1.1.2 .pod-nebori-cidra10.1.0.616 .service-cide192.16.1./20 ..ervice-dns-domain=linux39.local.能否初始化成功的关键第一点在于wip请求一定要将命令转发到172.31.3.103.6443所以可以查看103.6443在端口附近是否监听，rootakubeadm-master1:~# ss -tnl查看结果没看到6443，再等待一会，此时可以查看日志，观察有没有报错。root@kubeadm-master1:~# tail -f /var/log/syslog[kubele start] Initial timeout of 40s passed.等到时间都过了还没反应一定是哪里参数写的有问题，查看没有问题后继续等到。很明显是ipd地址还没有通，继续等待初始化，如果初始化能够通过的话会是如下一个结果。[addens] Appliod essential addonE kube 。proxyYour Kube rmetes control-plane has initialized successfully!之后需要进行以下这些操作。To start using your cluster, you need to run the following a5 a reqular user:sudo cp 1 /etc/ kube metes/ admin . conf $HOME/ . kube/configsudo cp 1 /etc/ kube metes/ admin . conf $HOME/ . kube/configsudo choun s(1d -u):$(1d .9) SHOME/ . kube/configYou should now deploy a pod network to the eluster.Run "kubect apply t [podnetwork],yomt: with one of the options Listed at: ,使用root权限添加master节https ://kube rnetes .10/ doc s/ one opts/c Luster administ rat ion/ addons/You can now join any number of control-plane nodes by copying certificate Buthoritiesand servlce account keys on each node and then running the following 05 root :kubeadn join 172 .31.7.248:6443 token Ofpghu。wt0t8adybh86jzvk..discovery- token Ca-cert hash sha256: oe2c43db9929b06c09465o4614112676f8c afb8009c8071f2ee14ledfc787 1. control. PlaneThen you can join any nunber of worker nodes by running the following on each 05 root:kubeadn join 172 31.7248:6443..token Ofpghu . rt0tBadybh86j zvk--discovery- token ca-cert hash sha256: ase2c 43db9929b06c094e6564614112676f8c afb80809c8071f2ee141edfc787rootekubeadn-moster1-运行结果：Unfortunately, an error has occurred:timed out waiting for the C onditionThis error is Likely caused by:The kubelet is not running运行kubeletroot@kubeadm-master1:-# systemctl satus kubeletUnknown operation satuskubelet. service，i kubelet: The Kubernetes Node Agentroot@kubeadm master1:~# systemctl status kubelet打开会继续进行初始化，可能会报错，并不影响。root@kubeadm- masterl:~# kubeadm init - - apise rver . adve rtise . address=172.31.3.101.. apise rve r-bind-port=6443 -control-plane- endpoint=172.31.3.248 ..ignore-preflight-errors=Swap .- image- reposi to ry= regist ry. cn -hangzhou. al iyuncs .com/ google_ containers/ .- kube rnetes-ve rsion=v1.17.2 --pod- network-cidr-10.10.0.0/16 --service-cidr=192.168.1. 0/20 ervice dns - domain=linux39. Local因为之前的初始化已经有数据了root@kubeadm- masterl:-# kubeadm reset[reset] Are you sure you want to proceed? [y/N]: y删掉数据再重新初始化，保证kubernetes数据启动时再进行初始化。root@kubeadm- masterl:~# kubeadm init - - apise rver . adve rtise . address=172.31.3.101.. apise rve r-bind-port=6443 -control-plane- endpoint=172.31.3.248 ..ignore-preflight-errors=Swap .- image- reposi to ry= regist ry. cn -hangzhou. al iyuncs .com/ google_ containers/ .- kube rnetes-ve rsion=v1.17.2 --pod- network-cidr-10.10.0.0/16 --service-cidr=192.168.1. 0/20 ervice dns - domain=linux39. Local重新查看日志：root@kubeadm- masterl:~# -f /var/log/syslog等待过后还是报错，可能是参数有问题。重新resetroot@kubeadm- masterl:-# kubeadm reset[reset] Are you sure you want to proceed? [y/N]: yroot@kubeadm- masterl:~# #kubeadm init - apiserver advertise address=172.31.3.101 - control plane- endpoint=172.31.7.248 --apiserver -bind-port=6443 - kubernetes version=v1.17.3 - pod-network- cidr= 10.10.0.0/16 --service cidr=172.26.0.0/16 --service dns domain=magedu.local -image repositregistry.cn-hanghou.aliyuncs.com/google. containers -ignore preflight- errors=swap在这个命令里，只有一些地址段与之前不一样，使用这个参数进行初始化。为1.17.3，会下载镜像，等到加载。root@kubeadm- masterl:-# kubeadm reset[reset] Are you sure you want to proceed? [y/N]: yroot@kubeadm- masterl:-#kubeadm init - . apiserver- advertise - address=172.31.3.101 - cont rol-plane endpoint= 172.31.3.248..apiserver bind-port=6443 - kubernetes-version=v1 .17.2 pod-network-cidr-10.10.0.0/16 -service-cidr-172.26.0.0/16 --service dns domain=magedu. Local -image repository= regist ry . cn-hangzhou .aliyuncs . com/ google containers -- ignore preflight errors= swap在这个服务器上有些端口已经被使用，所以重启服务器，rootigkubeadm- master1:-#root@kubeadm- master1:~# reboot或者换个节点，在别的节点初始化有可以。当在任何一个其他节点初始化之后，再将这个节点加入进来。root@kubeadm-master1:-# ss tnL^Croot@kubeadm- masterl:-# kubeadm init - apiserve r- adve rtise- address=172.31.3.101 .-Control- P Lane- endpoint=172.31.3 .248.apise rve r-bind-port=6443 - . kubernetes-version=v1.17.3 - pod-network-cidr=10. 10.0.0/16 --service -cidr=172.26.0.0/16 --service- dns . domain=magedu .local - image . repository=registry. cn hangzhou. aliyuncs .com/ google containersignore-preflight- errors=swap 如果环境没有问题，一般不会报错。端口已经被占用。root@kubeadm- masterl:~# kubectlresetroot@kubeadm asterl:~# kubeadmreset节点好像有问题，重新更改节点再进行。rootakubeadm-master2:-# kubeadm init.. apiserver advertise . address=172.31.3.102.-control-plane . endpoint=172.31.3.248 apiserver-bind-port=6443 -. kubernetes-version=v1.17.2 --pod-network-cidr=10.10.0.0/16 .. service-cidr=172.26.0.0/16 . service- dns domain=magedu . local . image- repository=registry. cn-hangzhou . aliyuncs.com/google containers ignore-preflight- errors=swap发现有些服务已经在运行，先将这些服务停止。root@kubeadm- masterl:~# systemctl stop kube apiserve r kube cont roller. manager kube- schedulerFatled to stop Kube-seheduter Ssernage UArY cieschedue setrice not nogereaservzce not Loaded;root@kubeadm- master1:-#1镜像下载完成之后又到了[wait . control-plane] Waiting for the kubelet to boot up the control pLane as static Pods from directory "/etc/ kube rnetes/manifests". This can take up to 4mOs发现6443端口已经运行，此时应该就可以转换过去了，需要保持haproxy能将其转化过去。root@hal:~# vim /etc/haproxy/haproxy. Cfgroot@hal:-# systemctl restart haproxyroot@hal:-#Your Kubernetes control-plane has initialized successfully!初始化成功，可能是环境有问题，但是102是可以初始化成功的。能够通过负载均衡再将这个值转化为自己，将自己初始化成为一个master。102节点起来后，会提供一些选项。[bootstrap-token] Creating the "cluster- info" ConfigMap in the ”kube public ”namespace[kubelet-finalize] Updating " /etc/kube rnetes/kubelet.conf" to point to a rotatable kubelet client certificate and key[addons] Applied essential addon: CoreDNS[addons] Applied essential addon: kube -proxyYour Kubernetes control-plane has initialized successfully!start using your cluster, you need to run the following as a regular user:这些运行需要一些权限，需要当前用户的权限，需要当前用户创建一个cube加目录，mkdir P $HOME/ . kube然后拷贝这个文件：sudo cp -i /etc/ kube rnetes/ admin . conf $HOME/ .拷到 kube/ config加目录里面。修改权限sudo chown $(id -u):$(id g) $H0ME/ . kube/config就可以执行kubectl 命令。root@kubeadm- master2：#kubectl get nodes,是查看，当前执行不了，所以以上操作是第一个操作，到服务器上获取这些资源信息。第二个是安装一个网络插件：You should now deploy a pod network to the cluster .Run "kubectl apply -f [podnetwork].yaml" with one of the options Listed at:可以到https://kube rnetes. io/ docs/ concepts/c Luster- administ rat ion/ addons/中查看用户所要安装的组件，第三个是可以使用以下方式假如一个control plane nodes。其实就是加入master。You can now join any number of control-plane nodes by copying certificate authoritiesand service account keys on each node and then running the following as root:kubeadm join 172.31.3.248:6443 - token fntc3t. ya020llpadlxdeh1 \--discovery- token-ca-cert hash sha256:b458498a54211d2dfc2e1994a8701213b75787d311ebbe2d973941267470b6e1 \--control-plane最常用的是下面这个：Then you can join any number of worker nodes by running the following on each as root:kubeadm join 172. 31.3.248:6443.. token fntc3t. ya020llpadlxdeh1 \--discovery- token-ca-cert hash sha256:b458498a54211d2dfc2e1994a8701213b75787d311ebbe2d973941267 470b6e1以上这些token以及返回的数据要注意记录下来，因为后面会用到。1.实际操作：4．1、创建加目录：root@kubeadm master2:~# vim /etc/kubernetes/admin.conf查看文件中的内容，源文件中记录了当前用户的正负信息，是由kubeadm生成的，然后指向了VIP：server：http://172.31.3.248.6433。所以在后期都会通过这个端口转入到三台master中的任一一台。认证信息，操作的时候会有端号：Users：-name:Kubernetes-admin意味着是个超级管理员，认证的时候并不是使用账号密码，而是使用密钥。所以这个地方放置的就是账号信息。只要拿到这个信息，就意味着对你的kbs有官方权限，所以文件得好好保存，不要放置到note节点上，否则会在所有的节点上都能够被认证，进行一些增删改得操作。显示Kubeadm master2.magedu.net NotReady master 3m54s v1.17.2这个是没有关系的，因为还没有安装网络组件，在没有安装网络组件之前，显示都是这样的。加入其他两个节点：加入103：在另外一台已经安装了docker、kubeadm 和kubelet的master节点上执行以下操作:。# kubeadm join 172.31.7.248:6443 -token 0fpghu.wt0t8adybh86jzvk \-discovery-token-ca-cert-hashsha256:aae2c43db9929b06c094e65a4614112676f8cafb80809c8071f2ee141edfc787 \--control-plane -certificate keyb66cd885cbd3b94cace2ddfad3037935ba3dabc63bf2aee0c28878b6857ac53bcertificate key 默认没有提供，所以需要在master中生成，在哪个节点上初始化就到哪个节点上去生成，相应得key文件。rootakubeadm- master2:~# kubeadm init phase upload-certs -upload-certsupload-certs] Using certificate keyaf6095c5993a06089b5380d149bfc091de279210dab84937 e2c8f4d96 j99dc7b复制af6095c5993a06089b5380d149bfc091de279210dab84937 e2c8f4d96 j99dc7bkubeadm join 172.31.3.248:6443 --token fntc3t 。ya02011pad1xdeh1 --discovery-token-ca-cert -hash sha256:b458498a54211d2dfc2e1994a8701213b75787d311ebbe2d973941267470b6e1 \二一control -plane-certificate- keyf6095c5993a06089b5380d149bfc091de279210dab84937e2c8f4d96199dc7b这个时候就可以将节点加入到kbs中去，并且是个master节点。然后点击回车，172.31.3也会拉入进去，所以等会master加入进去之后，master就会有两个，等待103也加入进去，今天的环境可能有点问题，所以加载比较慢。目前最好的做法先关闭不需要得服务器，不让它继续加载，只加载需要的服务器。不要向102和103中转化，因为102和103都没有启动。[preflight] You can also perform this action in beforehand using ' kubeadm config images pull先加入102跟103再解决101，这个节点有点麻烦，因为rest不掉。root@kubeadm- masterl:-# kubeadm reset[reset] Are you sure you want to proceed? [y/N]: y完成后与可以在上面重新加入进去。在加载的过程中也是对你的etcd进行扩容的过程。有一个创建etcd的步骤。在其中会生成一个新的etcd member,这个etcd mwmber就是新的节点。它将已经新的节点加入到已经存在的cluster中，这个cluster就是102的单节点。所以会将101节点进行扩容，扩容之后创建一个pod给etcd,.然后将etcd加入进去，加入之后etcd就变成两个节点了。rootakubeadm- master3:~# kubectl get nodeThe connection to the server Locathost:8080 was refused . did you specify the right host or port?root@kubeadm- master3:-#rootakubeadm- master3:~# kubectl get nodeThe connection to the server Locathost:8080 was refused . did you specify the right host or port?回到102中查看：[upload-certs] Using certificate key:af6095c5993a06089b5380d149bfc091de29210dab84937e2c8f4d96199dc7broot@kubeadm- master2:-# kubectl get nodesNAME STATUS ROLES AGE VAISIONkubeadm- master2. magedu . net NotReady master 9m38s vl.17.2kubeadm- maste r3. magedu net NotReady master 68s v1.17.2使用这个命令将101也加入进去：io/doc 101 kubeadm join 172.31.3.248:6443 --token fntc3t ，ya02011pad1xdeh1 \ -discove ry-token-ca-cert -hash[prefl sha256:b458498a5421 ld2dfc2e1994a8701213b75787d31 lebbe2d973941267470b6e1 \ control-plane --certificate-key[prefl af6095c5993a0608 9b5380d149bfc091de279210dab84937e2c8 f4d96199dc7b [prefl 102就变成三个节点了。也就是三个master。在101中加的时候依然会对etcd进行扩容。扩容成功查看root@kubeadm- master1:-# docker ps发现11秒12秒之前扩容了很多容器。包括kds的管理端，有controller等。root@kubeadm- master2:-# kubectl get nodesNAME STATUS ROLES AGE VERSIONkubeadm- maste r1. magedu .net NotReady maste r 40s v1.17.2kubeadm- maste r2. magedu .netNotReadymaste r11mv1.17.2kubeadm- maste r3. magedu .netNotReadymaste rt 2m33sv1.17.2观察到节点变成三个，发现并没有准备完成，所以这个时候需要装网络组件，组件怎么安装，需要查看返回值，刚才102创建完成之后，给了一个返回值You should now deploy a pod network to the cluster .Run kubectl apply -f [podnetwork.yaml" with one of the options listed at:https: / /kube rnetes . io/docs concept s/ cluste r- administ rat ion/ addons/可选项只能组装一个，那可选项有多少个呢。去查看ur1Calico is a networking and network policy provider. Calico supports a fexible set of networking options so you can choose the most efcient option for your situation, including non- ovehdy and overlay networks, with or without BGP Calico uses the same engine to enforce network policy for hosts, pods, and (if using Istio & Envoy) applications at the service mesh layer.2、Flannel is an overlay network provider that can be used with Kubernetes.点击查看kubect1 apply -f https ://ran. githubusercontent。com/coreos/flanne1/master/Documentat ion/k8s - nanifests/kube。 Flannel-legacy.ymlFor Kubernetes v1.7+ kubectl apply -f https://ran. githubusercontent。com/coreos/ flanne1/naster/Docunentat ion/kube- flannel ymSee Kubenfetes for more details.和我们的不一样就算直接安装也不能用，因为地址段不同，我们的地址段指向了172.6，而它的地址段默认是10.244.0所以这个组网用不了，必须改成我们自己的组网地址。root@kubeadm- master2:-# wget https :// raw . gi thubuse rcontent . com/ coreos/ flannel/ master/Documentation/ kube . flannel. Ymlroot@kubeadm master2:~# vim kube- flannel. ymlroot@kubeadm- master2:~# kubectl apply -f kube- flannel. Ymlroot@kubeadm master2:-# kubectl get nodesNAMESTATUS ROLES AGE VERSION root@kubeadm master2:-# kubectl get nodesroot@kubeadm master2:-# kubectl get nodesroot@kubeadm master2:-# kubectl get nodes查看node节点有没有变成read状态，因为在这个文本组件里面它也是创新的容器。容器也有镜像，镜像地址是：image: quay . io/coreos/flannel:v0.12 0- amd64是官方的镜像发布。有一个ok就意味着它将镜像下载下来了。如果实在下载不下来就找一个节点或者从外围网导入进来。导入进来传到自己的kube中去。再将镜像地址改成本机的，其实就是将image后的地址改成自己的hobe地址，改完之后就可以从内网下载镜像。这个时候从内网下载的时间就很快。root@kubeadm master2:~# vim kube- flannel. Ymlroot@kubeadm- master2:~#root@kubeadm master2:-# docker imagesrootdkubeadm- master2:~# kubectl get node s镜像一旦下载起来，网络组件就会检查成功，master就会变为ready，继而组装完成。Master组装完成之后就是添加nobe，就会比较简单。初始化完成之后master，将kubeadm 命令指定一下。Then you can join any number of worker nodes by running the following on each as root :添加工作节点node节点，每个节点使用root添加。kubeadm join 172.31.3.248:6443 --token fntc3t .ya02011pad1xdeh1 \-di scovery- token-ca-cert -hash sha256 :b458498a54211d2dfc2e1 994a8701213b75787d31 lebbe2d973941267470b6e1然后执行107，这个节点就会添加进去。而且速度很快。rootigkubeadm- masterz:-t KuDectL get nodesHAMESTATUSROLESAGE VERSION .kubeadm- masterl . magedu. netReadymaste r5m3sv1.17.2kubeadm- maste r2. magedu .netReadymaster15mv1.17.2kubeadm- master3. magedu . netReadymaster6m56sv1.17.2node节点只需要执行一下join命令，master会自动下发一些指令。这些指令就是让它去创建fflown，如果没有的话就是镜像下不来，可以等待一会，等到ok。两条初始化命令：kubeadm init -- api se rve r - adve rt ise- address=172.31.3.101 --apise rve r -bind port=6443 -- control -plane endpoint-172.31.3.248- ignore -pre f1 ight -er rors= swap -- image - repos i tory= reg ist ry . cn-hang zhou . a liyuncs . com/google containers/WO327 I- kube rnetes-version-v1.17.2 --pod- network-cidr= 10.10.0.0/16 --service-cidr-192.168.1.0/20| W0327se rvice -dns -doma in=linux39. local[init] 67kubeadm init- api se rver - advertise address-172 .31.3.102 -- control -plane endpoint=172.31.3.248[prefl- api server-bind port 6443 -- kubernetes -version-v1.17.2 - pod- network-cidr- 10.10.0.0/16 --service-cidr-172 .26.0.0/16--service -dns -domain-magedu. local -- image- repository- registry . cn hangzhou . al iyuncs . com/goog1e containersio/ doc-- ignore-preflight -errors=swap两条命令都一样，长度都一样，为什么第一条没有成功。只是域名跟地址段不同。初始化成功之后加入节点就是这麽简单，如果有服务器直接通过join节点将它填入进去就可以了。rootdnodel:~# kubeadm reset102 103都是同样的操作。自己测试可以使用，但是在公司不可以使用，因为是一种不可恢复的操作。第二种初始化方式：基于文件初始化高可用master方式:两种方式任意选择一种成功就可以，# kubeadm config print init defaults #输出默认初始化配置。先拿到默认的初始化信息，追加一下默认的初始化信息，将它追加成一个文件，rootgkubeadm- sterti # kubeadm config print init-defaults > kubeadm- init. Yml因为这个文件中很多值都是默认的，所以需要更改，Ttl:48h 0m 0s而且通过kubeadm初始化时也可以更改这个有效期。advertiseAddress:172.31.3103监听地址是本机的cIrSocket:/var/run/dockershim.sock文件不需要更改保持默认就可以。name: kubeadm- masterl，magedu . nettaintseffect: NoSchedulekey: node- role . kube rnetes . i0/ masterapiSe rve r :timeoutForControlPLane: 4m0sapiVe rsion: kubeadm. k8s . io/ vlbeta2ce rtificatesDir: /etc/kubernetes/ pkicluste rName: kube rnetescontrollerManager:controllerManager:Kubernetes version:v1.17.2Dnsdomain :linux39.localService subnet:192.168.1.0/20此地址不要使用国网地址，一定要使用私网地址。补全地址：注意这个过程不能使用tab键，要使用空格的方式来写，core仍旧使用coredns来写就行，imageRepository: registry . cn-hangzhou . aliyuncs . com/ google containers镜像地址要改成阿里云的，要使用谷歌地址肯定是不行的，或者使用代理或者翻墙。还缺少一个VIP的地址：clusterlame kubermetescontrolPlaneEndpoint: 172.31.3.248:6443然后确定一下行数，此时是26行。复制文件过来确定两个都是四十行。进行初始化：# kubeadm init -config kubeadm-init,yaml #基 于文件执行k8s master初始化。root@kubeadm- master1:~# kubeadm init --config kubeadm init . yml此时负载均衡要改成101，因为现在只有101这块装adm,root@kubeadm- masterl:-# LL /root/ ku^Croot@kubeadm- masterl:~# mkdir -P SHOME/ . kuberoot@kubeadm- masterl:~#root@kubeadm- masterl:~# sudo cp -i /etc/ kubernetes/ admin. conf $HOME/ . kube/configroot@kubeadm- masterl:-#root@kubeadm- masterl:-# sudo chown $(id u):$(id -g) SHOME/ . kube/configroot@kubeadm-master1l:~# llroot@kubeadm masterl:-# wget https://raw. githubusercontent . com/ coreos/ flannel/ maste r/Documentation/kube . flannel. ymL查看flannel文件是否能通，root@kubeadm-masterl:~# wget https : //raw. githubusercontent . com/coreos/ flannel/ master /Documentation/ kube- flannel . ymL --2020-03-27 15:18:00-- https:// raw. githubuse rcontent .com/ coreos/ flannel/ maste r/Documentat ion/kube flannel. Yml Resolving raw. githubuse rcontent. com ( raw . githubuse rcontent，com)..root@kubeadm-master1:~# wget https:// raw. githubuse rcontent，com/ coreos/ flannel/ maste r/Documentat ion/ kube- flannel. Yml或者打开后手动创建一下这个文件，root@kubeadm-master1:~#vim flannel.Yml然后将文件复制粘贴下下来，Nerwork:“192.168.0.0/20”就可以直接创建就可以。运行网络组件：root@kubeadm- master1:~# kubectl apply -f flannel. Yml按照之前方法将其他master节点和nobe节点都添加进来。root@kubeadm-masterl:-# kubeadm init phase upLoad-certs --upload-certs--ce rti f icate- key 2675 fddcc0fe36799bc2 689a2759c725a71c5d9cf 491 f f 3d0b96265dbc 6a0038在102跟·103节点中分别执行，就添加成功了。PLease, check the contents of the $HOME/ ，kube/config file.root@kubeadm- master3:~# kubeadm join 172 .31.3.248:6443. token abcdef . 0123456789abcdef )discovery- token-ca-cert -hash sha256 : 0e06f649c fb8dce5bcad 1a882283ca93308fc4fbfbb77a4ff19ad7fc758b4a5-control-plane --certificate- key 2675fddcc0fe36799bc2689a2759c725a71c5d9cf491f f3d0b96265dbc6a0038加入nobe节点：root@node1:~# kubeadm join 172. 31.3.248:6443.. token abcdef . 0123456789abcdef \--discovery- token-ca-cert -hash sha256: 0e06f649c fb8dce5bcadc 1a882283c a93308fc4fbfbb77a4ff19ad7 fc758b4a5]两种方式任选其一初始化成功就可以，来回初始化，只是为了说明两种方式都可以。root@kubeadm- masterl:~# kubectl get nodesNAME STATUS ROLESAGEVERS IONkubeadm- maste r1. magedu，netReadymaster4m43sv1.17.2kubeadm- master2. magedu .netReadymaste r54sv1.17.2rootakubeadm- masterl:~# kubectlget nodes确保两种节点都加入进去并且ready，集群就创建成功了，之后就是进行跑服。Ready之后就可以了，意思就是说集群已经起来了。这两种方式任选其一就可以，但是推荐使用文件的方式，因为当时使用了哪些参数，后期想更改也可以改。如果使用命令初始化，命令记录不太好找。kubeadm init创建k8s集群流程:https://k8smeetup.github.io/docs/reference/setup: tools/kubeadm/kubeadm init/finit workflow.
-
发表了文章 2022-11-17
环境初始化及 kubeadm 命令简介 | 学习笔记
开发者学堂课程【Kubernetes 入门实战演练2020版：环境初始化及 kubeadm 命令简介】学习笔记，与课程紧密连接，让用户快速学习知识。课程地址：https://developer.aliyun.com/learning/course/656/detail/10859环境初始化及 kubeadm 命令简介内容介绍一、K8s组件二、kubernetes 部署过程三、部署 harbor 及 haproxy 高可用反向代理四、在 master 安装指定版本的 kubeadm、kubelet、kubectl 和 docker本章讲解 kubernetes 的安装，前一章将开发的环境和服务器都已创建完成，下面介绍创建完成之后如何安装部署，安装部署按照之前的规划，Master上需要安装 Kube-controller-manager，kube-apiserver和 kube-scheduler，以及用来保证 k8s 数据的 etcd,同时还有 node 结点，每个 node 结点都需要安装多个 kubelet和kube-proxyK8s 核心优势:,基于 yaml 文件实现容器的自动创建、删除更快速实现业务的弹性横向扩容,动态发现新扩容的容器并对自动用户提供访问。更简单、更快速的实现业务代码升级和回滚。一、k8s组件1、k8s组件介绍:https://k8smeetup.github.io/docs/admin/kube-apiserver/kube-apiserver:KubernetesAPlserver为api对象验证并配置数据，包括pods、services、replicationcontrollers和其它api对象,APIServer提供REST操作和到集群共享状态的前端，所有其他组件通过它进行交互。https://k8smeetup.github.io/docs/admin/kube-schedulerkube-scheduler是一个拥有丰富策略、能够感知拓扑变化、支持特定负载的功能组件，它对集群的可用性、性能表现以及容量都影响巨大。scheduler需要考虑独立的和集体的资源需求、服务质量需求、硬件/软件/策略限制、亲和与反亲和规范、数据位置、内部负载接口、截止时间等等。如有必要，特定的负载需求可以通过API暴露出来。·https://k8smeetup.github.io/docs/admin/kube-controller-managerkube-controller-manager:ControllerManager作为集群内部的管理控制中心，负责集群内的Node、Pod副本、服务端点(Endpoint)、命名空间(Namespace)、服务账号(ServiceAccount)、资源定额（ResourceQuota）的管理，当某个Node意外宕机时，ControllerManager会及时发现并执行自动化修复流程，确保集群始终处于预期的工作状态。https://k8smeetup.github.io/docs/admin/kube-proxykube-proxy:Kubernetes网络代理运行在node上,它反映了node上KubernetesAPI中定义的服务，并可以通过一组后端进行简单的TCP、UDP流转发或循环模式（roundrobin))的TCP、UDP转发，用户必须使用apiserverAPI创建一个服务来配置代理，其实就是kube-proxy通过在主机上维护网络规则并执行连接转发来实现Kubernetes服务访问。https://k8smeetup.github.io/docs/admin/kubeletkubelet:是主要的节点代理，它会监视已分配给节点的pod，具体功能如下:向master汇报node节点的状态信息接受指令并在Pod中创建docker容器。准备Pod所需的数据卷返回pod的运行状态在node节点执行容器健康检查https://github.com/etcd-io/etcd-etcdetcd是CoreOS公司开发目前是Kubernetes默认使用的key-value数据存储系统，用于保存所有集群数据，支持分布式集群功能，生产环境使用时需要为etcd数据提供定期备份机制。https://kubernetes.io/zh/dbcs/concepts/overview/components/#新版本组件介绍。2、部署规划图3、安装方式:（1）部署工具:安装方式由多种，可以使用批量部署工具如(ansible/saltstack)安装但需要通过文件来安装、手动二进制、kubeadm、apt-get/yum等方式安装，以守护进程的方式动在宿主机上，类似于是Nginx一样使用service脚本启动。其中手动二进制是指官方提供的在脚本文件里的原始二进制部署的文件，将二进制放在指定目录后，生成一个sources文件最后将其运行即可，该方式较为复杂不做讲解。在早期1.8和1.9中使用过该种安装。该安装服务时常常要在官网上下载对应的二进制文件后再根据官方所给的部署脚本，去安装，同时最好依据官方脚本安装，否则将十分繁琐。所以如果对k8s的了解并不深，而使用二进制安装容易出错。其次如果不采用官方脚本就类似于最原始的安装，不仅更为复杂，还十分不好操作，因为所有操作过程都需要自行将文件日志一步步粘贴安装，还包括其中内部的证书等等，同时其中文件的参数也需要挨个配对，否则无法运行。同时对master部署其中的二进制文件也需要自行去gitHub找到官方的二进制文件下载。根据你自己需要的版本对应下载文档和脚本，再依次将client的linux64位：kubernetes-client-linux-amd64.tar.gz压缩包和ServerBinaries的kubernetes-client-linux-amd64.tar.gz，以及NodeBinaries节点的kubernetes-client-linux-amd64.tar.gz，将其四个放在一个目录下解压，解压完成后就会得到所有的二进制。之后就可以开始二进制的安装，但前提内部通信也是要基于证书去做验证，所以还需要生成证书，嵌入证书之后再进行部署等等，简而言之，二进制安装无法做到全自动，过于繁琐，因而被淘汰。所以采用批量部署工具如(ansible/saltstack)安装，同时在gitHub上也有许多开发爱好者科研出的ansible项目可以实现全自动化的方式部署k8s，使用起来也较为简单。kubeadm早期处于非正式，如今可以使用，但使用范围小。（2）kubeadm:在github也能够搜索到kubeadm的相关信息：1.什么是Kubeadm?Kubeadm是一种工具，旨在为创建Kubernetes集群提供最佳实践的"快迪路径"。但如今还未查得其含有正式开发版本，但在公司中已然可以使用。它以用户友好的方式执行必要的操作，以使最低限度的可行，安全的群集启动并运行。Kubeadm的范围仅限于本地节点文件系统和KubernetesAPl，它旨在成为高级工具的可组合构建块。2常见的Kubeadmcmdlet1)kubeadminit来引导初始Kubernetes控制平面节点。2)kubeadmjoin可以引导Kubernetes工作者节点或其他控制平面节点，并将其加入集群。3)kubeadm升级将Kubernetes集群升级到新版本。4)kubeadmreset可恢复通过kubeadminit或kubeadmjoin对主机所做的任何更改。https://kubernetes.io/zh/docs/setup/independent/create-cluster-kubeadm/#beta阶段。使用k8s官方提供的部署工具kubeadm自动安装,需要在master和node节点上安装docker等组件，然后初始化，把管理端的控制服务和node上的服务都以pod的方式运行。5)kubeadm介绍:“https://kubernetes.io/zh/docs/reference/setup-tools/kubeadm/kubeadm/#V1.10版本kubeadm介绍:https://github.com/kubernetes/kubeadm/blob/master/docs/design/design_v1.10.md6)安装注意事项:.注意:禁用swap，selinux，iptables.7)什么场景下使用KubeadmKubeadm是由官方出品，所以部署十分简单，使用场景多为开发，因为开发微服务时也需要基于容器去开发，开发时服务会自行搭建一个开发场景以便运行，也有可能由运维搭建，因为开发环境对稳定性要求不高，所以Kubeadm常被用于开发环境和测试环境，因为代码也需要测试其在容器中是否能够运行，所以常常都有两套环境，一套生产环境，一套测试环境。而其中的测试环境对稳定性的要求不高就可以使用kubeadm来搭建，在开发中可能会使用，相比运维就会考虑更加全面。ansible则倾向于kubernetes后期维护，以及后期想要快速的简单的添加新的master节点或node节点到k8s。假设机器运行的时间过长，需要更换其中的master，可以采用先购买一批服务器，将其先装入k8s中，加密后再将不用的下线，因为数据时存放在etcdclusterkey-value中的，所以只要SQL的数据不丢失，ｍａｓｔｅｒ就可以任意更换，由此使得ａｎｓｉｂｌｅ可以任意的升级和添加新节点。最后还能够进行ｋ８ｓ升级。kubeadm:部署简单，官方出品，使用场景:开发环境、测试环境ansible:kubernetes后期维护，怎么样后期快速的简单的添加新的master和node节点到k8s添加master需要安装的组件有：Ｋｕｂｅ－ａｐｉｓｅｒｖｅｒＫｕｂｅ－ｃｏｎｔｒｏｌｌｅｒ－ｍａｎａｇｅｒＫｕｂｅ－ｓｃｅｄｕｌｅｒ添加node需要的组件有：Ｋｕｂｅ－ｐｒｏｘｙＫｕｂｅｌｅｔk8s升级4.推荐ｇｉｔｈｕｂ项目－ｋｕｂｅａｓｚ该项目就是由Ａｎｓｉｂｌｅ脚本安装的ｋ８ｓ集群，其中的更新及时，一旦由新版本都会即使更新，在项目简介中可以看到当前是维护了ｖ１．１４，ｖ１．１５，ｖ１．１６和ｖ１．１９四个版本的维护。二、kubernetes 部署过程1.依据：添加master需要安装的组件有：Ｋｕｂｅ－ａｐｉｓｅｒｖｅｒＫｕｂｅ－ｃｏｎｔｒｏｌｌｅｒ－ｍａｎａｇｅｒＫｕｂｅ－ｓｃｅｄｕｌｅｒ添加 node 需要的组件有：Ｋｕｂｅ－ｐｒｏｘｙＫｕｂｅｌｅｔ依次将这五个在ｍａｔｅｒ和ｎｏｄｅ处安装即可。2.具体步骤当前部署版本为当前次新版本，因为后面需要使用kubeadm做kubernetes版本升级演示。目前官方最新版本为1.17.4，因此本次先以1.17.3版本kubernetes为例。同时如果当前公司安装的kubeadm版本满足操作的需求，不必再做ｋ８ｓ的升级，而应该在ｂｕｇ无法解决和需求无法满足时，再选择升级。3.升级ｋ８ｓ遇到的报错－－以滚动节点升级的方式解决早期用１．９的ｋ８ｓ，而在１．１１时候支持了IPVS而此时并不算正式版本，而是测试版，但在团队的统一认为下，1.9不足以支撑今后的业务，所以就决心向１．１１的ｋ８ｓ进行升级。此时面临的是跨两个版本的升级，因而通过找一个1.9的生产环境，升级过程中安插监控，然后找到漏洞之处，以防止在升级时候影响到业务功能。最后使用的是滚动升级，滚动升级即先从HAPｒｏｘｙ中将一个ｍａｓｔｅｒ下线然后进行离线升级，升级完成后再下线另一个，同时将其上线，依次类推，完成所有ｍａｓｔｅｒ的升级。同时最后一个ｍａｓｅｔ－３下线后先查看其他两个ｍａｓｔｅｒ的情况，如果没有问题再通过同样的方式，将ｎｏｄｅ节点也做滚动升级，同时当前ｎｏｄｅ节点做升级时，会被强制驱逐，即ｋ８ｓ将其容器重建，并取走节点上的容器，让其进行升级。升级完毕后再次添加。假设有50个ｎｏｄｅ节点，在测试没有问题的情况下，一次性升级10-20台，升级之后再将其加进来让ｋ８ｓ将ＮｏｄｅＰｏｒｔ平衡一下，即再将其50个节点当作原先的10个节点去下线把ｐｏｒｔ赶走使其迁移至其他节点。该为动态迁移一般不会影响用户访问。最后就是以滚动升级节点的方式解决了跨2个版本的升级。同时除了滚动升级，还可以选择重新部署一套1.11版本的ｋ８ｓ再重新将所有服务在新版本中运行，然后将原先的直接下线即可，但这种操作过于浪费，一般不做使用。同时小文件之间的升级不会有过大改动，当需要跨版本升级时，首选的就是此次介绍的滚动升级。(1)基础环境准备(2)部署harbor及haproxy高可用反向代理(3)在所有master安装指定版本的kubeadm（用于部署集群）,kubelet（负责注册到k8ｓ中去）、kubectl（客户端命令）、docker（是以容器化的方式创建的客端，只不过是在创建容器的时候做了端口映射，传了些运行参数而已）。(4)在所有node节点安装指定版本的kubeadm、kubelet、docker，在node节点kubectl为可选安装，看是否需要在node执行kubectl命令进行集群管理及pod管理等操作。ｎｏｄｅ节点需要安装kubeadm是因为之后要将ｎｏｄｅ结点架到kubeｃｔｌ集群中需要kubeadm命令才能够实现。所以任何一个节点都要安装。ｎｏｄｅ节点不需要安装kubectl因为它是一个客户端命令，意味着要想在哪个节点上执行命令行的操作时，就在哪个节点放置kubectl，而我们的ｎｏｄｅ结点仅仅是容器，而非执行命令的场所，所以不必放置kubectl，kubectl会依赖于kubectlｃｏｎｆｉｇ文件，想在哪个结点执行命令行文件只需要在此结点放ｃｏｎｆｉｇ文件即可。(5)master 节点运行 kubeadminit 初始化命令(6)验证 master 节点状态(7)在 node 节点使用 kubeadm 命令将自己加入 k8smaster(需要使用 master生成token认证)(8)验证 node 节点状态。(9)创建 pod 并测试网络通信,(10)部署 web 服务 Dashboard(11)k8s 集群升级。4、基础环境准备服务器环境:最小化安装基础系统，并关闭防火墙selinux和swap，更新软件源、时间同步、安装常用命令，重启后验证基础配置角色：k8s-master1主机名：kubeadm-master1．magedu.net.IP地址：172.31.3.101.三、部署harbor及haproxy高可用反向代理1.概念引入这一步并非是必须的，仅仅是在公司中会运用到，如：从公司内部的hanbor去拉镜像的情况。而 kubeadm 是采用容器启用的管理服务，而管理服务需要使用镜像，而镜像包含国外网站下载地址，本地是没有的。所以必须在本地搭建 habor 提前将镜像下载下来，然后再传给本地的 habor，而此处的 habor 是为了保护本地的镜像，此镜像通常会提供一个专门的镜像服务器，即一堆 Dockerfile，通过 Dockerfile 来制作镜像。 而Dockerfile中需要含有代码，而代码就通过gitlab而来，即从开发的电脑将写完的代码传入gitlab，之后在向领导发邮件，申请上线测试，允许测试后，运维再通过jenkins进行代码升级，jenkins是在gitlab对镜像服务器进行克隆后再编译，编译运行后就会自动传给harbor。传给harbor后，镜像就出现了，但它并不会自动传给node结点下载，只有当运维采用脚本能直接再kubeadm的master上执行代码升级指令，同时为已经认证好的。所以不论是kubeadm的master权限还是jenkins权限都是十分严格的。同时也会jenkins上编写脚本使得开发可以在kubeadm的master上执行代码升级，访问HAProxy也行。同时当升级指令到达master执行后，就会给node节点下发创建新容器的指令，而创建容器就会由kubelet和kubecontroller一起完成创建。最终创建的操作会分到各个节点去执行，分到哪个节点，哪个节点就需要配好镜像以便提前下载。此时节点就会自动从harbor上将镜像下载下来，下载到节点后kubelet就会重新基于新版本的镜像将容器重新创建，创建之后再将旧版本的容器删除，删除之后用户的访问自然而然就会到达新版本的容器。至此整个代码升级的过程就全部完成了。从此可以看出对于k8s而言，它的代码升级完全是基于镜像来实现的。2.安装过程来到harbor控制台，输入命令行：~#ll~#cd/user/src//sr~#ll~#aptinstall^C再将docker安装的脚本直接拖入控制台传输后采用脚本安装以节约时间，输入以下命令行，等待执行~#bashdocker-install.sh之后再将harbor准备好，因为之后的代理可能会使用，运行命令：~#aptinstallhaproxykeepalived运行中提示Doyouwanttocontinue?[Y/N]选择y即可，等待haproxy安装成功。Docker已经安装之后再安装docker-compose~#aptinstalldocker-compose运行中提示Doyouwanttocontinue?[Y/N]仍旧选择y，同时注意如果是跑容器kubeadm的，最好是采用windows，不要使用centOS,centOS8还可以但是7的内核稍旧，有许多是不支持。所以最好还是使用windows来跑k8s。上一步安装完成后，在Docker文件夹的准备资料中找到harbor-offline-installer-v1.7.6版本。将其传到user/local/src下。在harbor控制台找到文件位置，直接将压缩包拖入下载即可。将其换成域名的方式通过DNS解析。传完之后，输入命令将其解压：~#c/user/local/src/~#ll#tarxvf将harbor压缩包解压后进入到habor的目录~#cdharbor/\之后编译harbor的配置文件,同时注意：/user/local/src/harbor目录下执行该命令。~#vimharbor.cfg之后找到其hostname域名将其改为harbor.linux39.com后期在公司就只需要将harbor.linux39.com指向172.31.3.105即可，同时将kubeadm的master节点和node节点上的DNS的值变为公司内网的DNS即可，至此就完成连接了。最后将配置中的密码harbor_admin_password更改123456方便记忆，之后就可以进行安装。在/user/cocal/src/harbor目录下，执行命令：./install.sh等待安装即可。同时在公司中都含有PowerDNS,公司的自定义名和harvor的地址都是通过PowerDNS来解析的，同时node节点也会到达PowerDNS来解析。在权威机构中，假设域名为自行创建的记录PowerDNS就会直接向服务器返回，如果不是的情况就会将其转换为公网地址，如：223.6.6.6转化为阿里云或者其他的域名商下，至此就完成了公网的域名解析同时容器中含有PowerDNS和内部的coreDNS解析，如果内部解析无法解析，就会在coreDNS进行配置，将其通过网络转发先转发到内部的PowerDNS，因为容器需要连数据库或其他公司内部服务或是其他API，API是写了公司内部的域名，此域名只有PowerDNS才可以解析，所以就会将容器先在coreDNS解析，判断是否是内部的域名，是则在coreDNS直接返回服务器，如果是一些公司外部的接口访问，coreDNS无法解析则来到PowerDNS来转化为外网223.6.6.6解析。至此完成所有的域名都可以解析。当上一步执行的安装命令完成后，显示Nowyoushouldbeabletovisittheadminportalathttp://harbor.linux39.com则表示可以访问，将http://harbor.linux39.com放至浏览器网址搜索栏，但此时还没有域名，所以必须添加一个hostname。在电脑的Windows->System32->drivers->etc的hosts文件中添加一个172.31.3.106的解析，将172.31.3.106后的地址改为harbor.magedu.com，将其变为一个本地的ip地址再次使用harbor.magedu.com网址访问。同时注意要将代理模式去除，则能够成功看到以下画面。输入账号密码登录，即可成功访问。至此harbor就换为了域名，而不在是ip地址访问的状态。安装完成harbor后，将其的配置完成。输入命令：~#find/-namekeepalived.conf*找到vrrp结尾的配置文件使用命令：~#vp^C和~#cp/user/share/doc/keepalived/samples/keepalived.conf.vrrp/etc/keepalived/keepalived.conf将其配置文件拷贝到/etc/keepalived/keepalived.conf目录下。再通过命令:~#vim/etc/keepalived/keepalived.conf编译该文件。修改代码，使用VI_1这个vrrp假设为172.32.2.248来做负载均衡，用devehto网卡，同时router_id改为56为了方便不冲突。更改后如下：vrrp_instanceVI_1{stateMASTERinterfaceeth0garp_master_delay10smtp_alert.virtual_router_id56priority100advert_int1authentication{auth_typePASSauth_pass1111}virtual_ipaddre{172.31.3.248deveth0labeleth0:1}}最后输入命令：~#systemctlenablekeepalived重新启动，再输入~#ifconfig命令，发现并未正常显示，输入命令：~#vim/var/log/syslog查看日志是否有报错信息，同时输入指令：~#systemctlstatuskeepalived查看状态，发现文件状态错误，并未启动，最后问题为文件名错误，etc/keepalived/keepalived.conf并非是etc/keepalived/keealived.conf,少了p,重新更改后，再次输入，命令~#restartkeepalived和~#systemctlstatuskeepalived查看状态为active(running)即可。下一步配置一个节点即可，只需配置出节点的效果即可。只要演示出vrrp的效果，使得kubeadm能够通过vrrp访问即可。在此演示104节点，通过vrrp来访问kubeadmmaster的效果。访问的过程是运维通过vrrp而不是kubeadmmaster。Vrrp安装成功后，配置haproxy，首先编译haproxy：~#vim/etc/haproxy/haproxy.cfg，再最后添加名为k8s-api-6443的监听，其中check为设置检查机制，间隔时间3s，fall失败3次，rese恢复5次。同时在安装时时按照顺序，依次安装master1,master2,master3的，所以在此先安装master1即可，在此添加上也行。添加代码如下：listenk8s-api-6443bind172.31.3.248:6443modetcpservermaster1172.31.3.101:6443checkinter3sfall3riseservermaster2172.31.3.103:6443checkinter3sfall3riseservermaster3172.31.3.103:6443checkinter3sfall3rise添加完成后将其重启即可，输入命令：~#systemctlrestarthaproxy让其处于监听状态，再执行命令：~#ss-tnl查看172.31.3.248：6643的监听情况，之后再做各种负载均衡的切换。等待harbor以及haproxy高可用反向代理安装全部完成后，就可以开始测试是否可以真正使用。四、在 master 安装指定版本的 kubeadm、kubelet、kubectl 和 docker1.基础环境准备服务器环境:如果为centOS最小化安装基础系统，需要关闭防火墙selinux，最好不需要使用swap，更新软件源、将时间同步、安装常用命令，重启后验证基础配置即可。同时要注意时间同步十分关键。2.安装kubeadm等组件在master和node节点安装kubeadm.kubelet、kubectl、docker等软件。安装时要注意选择k8s兼容的版本，如果安装的为早期的，需要在官方提供的文档中查找docker版本，直接搜索需要的版本，可以查看到有些组件有所变化，而有些组件没有。如图示例的，搜索17.03就可以看到Unchanged未变化的组件，同时docker支持13.1,17.03,17.09,18.06,18.09版本，而并没有标注docker19.03就说明docker19.03版本在k8s1.16版本并没有进行测试。而没有经过测试的版本就尽量选择不做使用。简而言之就是，在使用docker版本时一定要使用当前k8s能够兼容的版本。（1）所有master和node节点安装docker:在此演示安装的docker版本为19.03，直接在阿里云中搜索kubernetes。其中的文档显示了Debian/Ubuntu和CentOS/RHEL/Fedora两类，将各种源安装即可。1安装docker-在mater1上执行首先安装19.03版本的docker，先在阿里云中搜索docker将docker的安装传送命令框中。提示传送完毕后。查看其中的配置信息，将指定的版本安装去除。因为此时需要的docker版本为19.03，而此时传送的docker不匹配，所以此时输入命令：~#vimdocker-install.sh查看脚本内容，将其中指定的安装版本去除后就可以自动安装最新的19.03版本。配置内容如下（红色为更改部分）：#!/bin/bash#step1:安装必要的一些系统工具sudoapt-getupdatesudoapt-get-yinstallapt-transport-httpsca-certificatescurlsoftware-properties-common#step2:安装GPG证书curl-fsSLhttps://mirrors.aliyun.com/docker-ce/linux/ubuntu/gpg|sudoapt-keyadd#SteP3:写入软件源信息sudoadd-apt-repository"deb[arch=amd64]https://mirrors.aLiyun.com/docker-ce/linux/ubuntu$(lsb_release-cs)stable"#Step4:更新并安装Docker-CEsudoapt-get-yupdatesudoapt-get-yinstalldocker-cedocker-ce-clihttps://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG.1.17.mdidownloads-for-v1174#安装经过验证的docker版本。最后再执行命令：~#bashdocker-install.sh，将docker安装。安装成功后再验证是否是最新版本的节点。2master2上执行命令：~#vimdock-install.sh来安装dock，执行后再将以下配置信息添加进去，最后输入命令:q!。配置信息如下：#安装必要的一些系统工具#sudoapt-getupdate#apt-get-yinstallapt-transport-httpsca-certificatescurlsoftware-properties-common.安装GPG证书#curl-fsSLhttp://mirrors.aliyun.com/docker-ce/linux/ubuntu/gpgIsudoapt-keyadd写入软件源信息#sudoadd-apt-repository"deb[arch=amd64]http://mirrors.aliyun.com/docker-ce/linux/ubuntuS(lsb_release-cs)stable"更新软件源#apt-get-yupdate查看可安装的Docker版本。#apt-cachemadisondocker-cedocker-ce-cli安装并启动docker19.03.8:#aptinstalldocker-ce=5:19.03.8~3-0rubuntu-bionicdocker-ce-cli=5:19.03.8~3-0~ubuntu-bionic-y#systemctlstartdocker&&systemctlenabledocker验证docker版本:。dockerversion同时可以将脚本分发到master2上，再批量执行，输入命令：~#scdocker-install.sh^C将脚本拷贝，拷贝之前可以输入命令：~#dockerversion验证版本是否正确。之后再输入命令：~#dockerversion^C和~scpdocker-install.sh172.31.3.102:/root，表示将docker-install.sh的所有master和所有node都拷贝至172.31.3.102中，由此达成102为一个master，103为一个master。最后依次输入：~scpdocker-install.sh172.31.3.103:/root~scpdocker-install.sh172.31.3.107:/root~scpdocker-install.sh172.31.3.108:/root~scpdocker-install.sh172.31.3.109:/root同时如果节点过多，可以采用写循环的方式去实现，此处就采用挨个手敲。在mater拷贝完成后，来到各个172.31.3.102，172.31.3.103，172.31.3.107和172.31.3.108,172.31.3.109分别执行命令：~#bashdocker-install.sh将docker安装即可。（2）master节点配置docker加速器添加加速器后在公网上下载镜像会更加快，同时并非所有的节点都会配置加速器，因为大部分的node节点都会寻找本地的harbor去下载镜像而不会去外网下载镜像，所以只需要在镜像服务器，才有可能从外网下载镜像，所以只需在可能前往外网下载镜像的镜像服务器上配置即可，所以将以下命令行复制到命令框执行即可。#sudomkdir-p/etc/docker.#sudotee/etc/docker/daemon.json<<-'EOF'{"registry-mirrors":["https://9916w1ow.mirror.aliyuncs.com"]}EOF.#sudosystemctldaemon-reload&&sudosystemctlrestartdocker（3）所有节点安装kubeletkubeadmkubectl:所有节点配置阿里云仓库地址并安装相关组件，node节点可选安装kubectl,并非一定需要安装。在此我们需要在每个master和node节点中挨个执行以下命令，而harbor则不用。同时注意如果没有key文件，在之后配置完成阿里云的镜像源之后更新会报错。按照官方配置方法依次配置，直到最后安装kubelet、kubeadm和kubectl命令源之前就可以输入命令：~#apt-cachemadisonkubeadm查看能够安装的kubeadm版本，同时kubeadm和kubect无法跨版本，所以需要哪种的就执行那种即可。在此安装kubeadm1.17.2版本，同时如果安装时不指定版本则默认为最新版本。执行命令：~#apt-cachemadisonkubeadm=1.17.2.00kubectl=1.17.2.00kubelet=1.17.2.00来指定其安装版本,最后在每个master都执行命令：~#aptinstallkubeadm=1.17.2.00kubectl=1.17.2.00kubelet=1.17.2.00使master都安装上。在node节点上也可以安装上，同时node节点不需要执行kubectl=1.17.2.00命令,同时也并不安全，所以就可以将其在安装时去除，变为：~#apt-cachemadisonkubeadm=1.17.2.00kubelet=1.17.2.00。阿里云官方安装方法：配置方法（都是在每个master和node节点中执行）Debian/Ubumu(先升级安装https)apt-getupdate8&apt-getinstall-yapt-transport-https（添加阿里云镜像的key文件，将其下载下来）curlhttps://nirrors.aliyun.com/kubernetes/apt/doc/apt-key.gpg|apt-keyadd-（下载完key文件后，安装文件源，将kubernetes的源指向阿里云）cat<<EOF>/etc/apt/sources.list.d/kubernetes.listdebhttps://mirrors.aliyun.com/kubernetes/apt/kubernetes-xenialmainEOF（需要手动输入，否则无法执行）（更新以下）apt-getupdate（就可以安装使用kubelet、kubeadm和kubectl命令源）apt-getinstall-ykubeletkubeadmkubectl1镜像仓库配置:配置阿里云镜像的kubernetes源(用于安装kubeletkubeadmkubectl命令)https://developer.aliyun.com/mirror/kubernetes?spm=a2c6h.13651102.0.0.3e221b11IXALy62所有服务器点安装kubeletkubeadmkubectl:#apt-getupdate#安装指定版本kubeadm查看版本信息#apt-cachemadisonkubeadm安装kubeadmkubectlkubelet#aptinstallkubeadm=1.17.3-00kubectl=1.17.3-00kubelet=1.17.3-00启动并验证kubelet#systemctlstartkubelet&&systemctlenablekubelet&&systemctlstatuskubelet3验证master节点kubelet服务:注意kubeadm，kubectl和kubelet，其中只有kubelet是服务，其余是命令，所以需要验证收集当前的资源向master汇报，但是它启动时需要一些配置，否则便会报错，提示xx文件不存在：而因为此时还未做初始化，所以输入命令：~#vim/var/log/systemlog查看日志可以看到一定是报错的情况。（4）master节点运行Kubeadminit初始化命令：在三台master中任意一台master进行集群初始化，而且集群初始化只需要初始化一次，因为集群初始化后就会写入etc中，再次初始化又会重置一遍，同时第二次初始化后其中已经含有数据，所以再次初始化容易失败，所以只需其中一个master执行即可，之后的master只需要加到之前的节点中去即可，加之后会自动的给新的master安装管理端。输入命令：~#kubeadm--help可以查看其中的示例（如图），其中的详细信息在其中的网址中：http://github.com/kubernetes/kubeadm/issues,将其复制到浏览器打开即可看到相关的说明。从其中的使用实例能得到，它需要创建两个节点的cluster和一个control-plane（控制平台，此处指高可用的vrrp），而看k8s保证高可用是通过vrrp在负载均衡之间实现的。当一个节点挂了，vrrp会基于后端服务器探测，将用户端请求转到完好的master2或者3，但是在实际测试中，一个节点挂了后，其他的节点都不能够再使用。，而使用是通过第一次运行服务器时就采用kubeadminit服务器初始化的操作。初始化后的第二次操作，只需采用kubeadmjoin的方式添加参数，该参数是在初始化时能够将其返回的，将其节点加入到kubeadm的master即可。代码说明如下：Exampleusage:Createatwo-machineclusterwithonecontrol-planenode(whichcontrolsthecluster),andoneworkernode(whereyourworkloads，likePodsandDeploymentsrun).Onthefirstmachine:control-plane#kubeadminitOnthesecondmachine:worker#kubeadmjoin<arguments-returned-from-init>Youcanthenrepeatthesecondstep1Kubeadm初始化命令使用：初始化的命令包含以下几个：AvailableCommands:1）alpha#kubeadm处于测试阶段的命令，一般不做使用2）completion#bash命令补全，需要安装bash-completion，安装后在书写时会自动补全参数，需要通过指定SHELL来进行配置，一般将其放在脚本中，在之后使用时只需导入脚本即可。输入以下命令：#mkdir/data/scripts-p#kubeadmcompletionbash>/data/scripts/kubeadm_completion.sh（做输出重定向，将其放在脚本中）#source/data/scripts/kubeadm_completion.sh（指定source)#vim/etc/profile(配置文件，将以下source文件放在其中)source/data/scripts/kubeadm_completion.sh再执行命令：chmoda+x/data/scripts/kubeadm_completion.sh将其添加。最后再执行命令：~#kubeadm命令按下tab键就会发现成功补全了，如果没有出现，那么再重新输入source/data/scripts/kubeadm_completion.sh命令后重试即可。至此就可以完成自动补全的功能，当编写时忘记语句参数，只需按tab键就会自动出现所有命令支持的参数或直接补全。最后即便程序重启后，自动补全功能也仍然存在。3）config在命令行输入kubeadmconfig--help就可以出现对其config参数的解读。#它主要是管理kubeadm集群的配置，该配置保留在集群的ConfigMap中.configMap是kubeadm的一个配置文件映射，由此实现当配置不放在配置文件中，也能够将其放在文件中然后取名，再通过名称使得port基于名称去得到创建的配置文件，这种配置文件的类型成为ConfigMap。输入以下命令，就可以查看默认情况下执行的操作：#kubeadmconfigprintinit-defaults如果想要更改默认情况的属性，只需要将输出直接重定向成一个文件，命令：#kubeadmconfigprintinit-defaults>kubeam-1.17.2.yml将其重新输出，之后再使用命令:~#vimkubeam-1.17.2.yml去编译这个文件，在文件中将需要更改的参数更改即可。4）helpHelpaboutanycommand5）init项目中使用最多的就是hep,常用其来初始化开发的集群，输入指令：~#kubeaminit--help可以去查看详细内容。#启动一个Kubernetes主节点6）join容器都是跑在容器上的，添加的节点没有限制，但一个节点上的容器是有限制的，可以添加node节点，也可以添加master，因为k8s需要使用节点部署成多master节点，因而不能在每个节点都执行一次初始化，这样容易导致某些认证数据等被覆盖掉，所以通常都是初始化一次，再将其他的节点加入进来，执行命令：~#kubeamjoin--help可以查看说明，其中join要指定api节点的地址和Flags,flag在其中也有许多。Usage:kubeadmjoin[api-server-endpoint][flags]Kubeadmjoin[command]#将节点加入到已经存在的k8smaster.7）reset还原使用kubeadminit或者kubeadmjoin对系统产生的环境变化。即当你无论是使用kubeadm对系统初始化或在master节点和node节点上通过客户端后需要返回初始数据，就可以使用reset将节点清空，或者是重装系统。reset同时也会将所有的数据清空。在生产环境切勿轻易使用reset命令（注意：不能轻易执行，执行后节点的数据会全部清空）8)token#管理tokentoken命令主要是用于管理token的,当我们想要访问其他api时，要么使用账号和密码作验证，但通常采用第一次访问会认证，之后会返回一个token，之后再次访问直接拿token访问api即可。同时token也是有过期失效的，当过期后就意味着当再次将新的节点加入之后就不能够使用了，就必须重新生成一个token，才能实现添加节点。9)upgrade#升级k8s版本10)version#查看版本信息一个节点上的容器是有上限的，如果在一个node节点上想要启动更多的容器就需要更改参数，就可以达到超过上限。以上就是所有Kubeadm初始化命令的使用。
-
发表了文章 2022-11-16
Sigfillset 函数｜学习笔记
开发者学堂课程【物联网开发- Linux 高级程序设计全套视频：Sigfillset 函数】学习笔记，与课程紧密联系，让用户快速学习知识。 课程地址：https://developer.aliyun.com/learning/course/660/detail/11018Sigfillset 函数 内容介绍一、Sigfillset 函数二、操作 一、Sigfillset 函数概述初始化一个满的信号集，集合当中有所有的信号，所有的信号都被添加到这个集合中了，用法和空集合一样。初始化一个满的信号集#include<signal.h>int sigfillset (sigset_t *set)功能:初始化信号集合 set，将信号集合设置为所有信号的集合。参数:信号集标识的地址，以后操作此信号集，对 set 进行操作就可以了。返回值:成功返回 0，失败返回-1。二、操作定义一个set2，sigset t set2; int ret;ret = sigfillsel (&sel2);就给set2这个集合赋值了，set2包含了所有信号。成功返回0，失败返回非0。
-
发表了文章 2022-11-16
电商项目之项目背景介绍｜学习笔记
开发者学堂课程【新电商大数据平台2020最新课程：电商项目之项目背景介绍】学习笔记，与课程紧密联系，让用户快速学习知识。课程地址：https://developer.aliyun.com/learning/course/640/detail/10489电商项目之项目背景介绍 内容简介：一、项目背景二、操作演示 一、项目背景随着时代的进步，信息化和数字化是现代的名词，而且现在网上用户逐年增多，各式各样的网上 APP 不断推出，尤为明显的就是电商行业，它解决了大部分用户的网购欲望。那么要想做好一个电商平台必须要有数据和信息的支持与管理，所以此项目主要是实现电商平台的数据管理和数据分析，为公司提供战略调整提供数据支持。二、操作演示：电商平台：来哇云商 来哇云商为本次做数据采集的一个电商平台，数据如果是用户边点边产生，则效率太慢。采用直接将数据设计好，发送到对应的hdfs 即可。但正常的数据是从电商平台上用户的行为操作，即用户的点击、搜索、浏览等等一系列用户在网站上的操作行为收集过来的数据，这些数据我们会通过一些埋点日志和业务数据库来收集，业务数据库一般都是收集人们跟订单有关的数据，这方面的数据是属于比较隐私的，需要保存到数据库中。以上是我们内部电商平台，里面也有商品，这些商品我们都可以去获取用户的行为日志。在这个后台给大家一个数据文件分析即可，当然正常情况下肯定是通过后台的服务器来采集数据，然后落地到本地磁盘或者 hdfs 中,业务数据就存在 mysql 数据库中关于平台上的数据如何获取，如何编号都是什么意思将会在后面详细介绍。 三、平台后台管理中心：有的人有一些开发商店，我们进行数据分析，包括他们做 Java，最后统计出来的数据都需要使用，我们大数据统计出来的结果也要使用，比如说我们会统计今天的新增铺有多少，店铺销售记录有多少，店铺区域分布有多少，都是有可视化页面的，最后处理完后，会给到后端数据库，通过后端数据库，读取后端 mysqal 口，里面的数据，然后进行一个前端的展示，也就是做一个 BI 可视化。然后下方还有我们购买的详情记录，以店铺为维度求最新结果，输入时间进行检索。后面还有会员分析，有新增会员，会员区域分析，会员等级分析，会员消费排行，这些都会通过 mysqal 进行操作然后被大数据分析，然后拿到结果进行前端展示。这些都是给后台分析和管理员看的。他们可以查看销售额，还有行业分析，还能查看用户积分明细、客户统计、订单统计、会员排行、销售购买率等。后台管理平台不只有财务，还有第三方服务，商城都有。平台是针对于用户的 log 进行统计分析，商城是针对店铺进行统计分析，财务是以平台加商城分析金钱有关的东西。APP 获取买点日志，也会进行业务分析。 总结：我们要做的就是一个电商平台的项目，针对于我们的电商的用户或者说用户的行为操作来去分析，去实现一个数据仓库。
-
发表了文章 2022-11-16
Lua 脚本读取 redis 数据｜学习笔记
开发者学堂课程【大数据实战项目：反爬虫系统（Lua+Spark+Redis+Hadoop 框架搭建）第一阶段：Lua 脚本读取 redis 数据】学习笔记，与课程紧密联系，让用户快速学习知识。 课程地址：https://developer.aliyun.com/learning/course/669/detail/11610Lua 脚本读取 redis 数据 内容介绍一、 前情回顾二、 Lua 脚本读取 redis 数据三、 运行代码四、 总结 一、 前情回顾要连接 redis 去获取数据首先得有 redis 实例，实例需要 new, 超时可以设置timeout, 有了实例还需要连接数据库，连接以后要读取数据或者是写入数据，其他的暂时不需要了解local ok , new _ tab peal1( reqruire ,＂ table . new ＂)if not ok or type ( new _ cab )~= ＂ function ＂ then new_tab=function(narr,nrec)return()endend local_ M = neW _ tab (0,54)_M_VERSION=0.26!local common_cmds=｛local sub comumands ＂ subscribe ＂,＂ psubscribe ”local unsub _ eommands ={＂ unsubscribe ＂,＂ punsubscribe ＂local mt{_index＝_M_｛｝function _ M. new ( sel f)local sock , err tcpO )if not sock thenl return nil ，errend return setmetatable (_sock=sock,_ subscribed = false )end function _ M.set _ timeout ( self , timeout )local sock rawget (se1f,＂_ sock ”)if not sock then return nil ,＂ not initializedend return sock : settimeout ( timeout )endfunctionM . connect (self ·)LocalSockTaWget(self,＂ sock ＂)if not sock then return nil ,＂ not inicialized＂ end self_ SubsCribed = falsereturn sock: connect (..) end function _ M . set _ keepalive ( self ,local sock rawget ( self ,＂_ sock ＂)if not sock then retarn nil ,＂ not initialized ”end if rawget (se1f,retarn nil ＂ subscribed ") then ＂ subscribed state ＂ 二、 Lua 脚本读取 redis 数据只需要在流程中把数据读出来，读到 lua 脚本中流程打通就可以了，剔除的操作由前端工程师实现，接下来就进行操作，写脚本在 shell 窗口不是很方便，所以在windows 新建脚本，在这里面写，写好上传上来就行。编写读取数据的脚本思路:写读取 redis 数据先引入 redis 包,包是 web 包没在脚本中，这就涉及到了如何引入 web 包，前面课程中已经讲过，类似于 java 中的 import 这里面叫 require。引入以后实例化一个 redis 对象，用对象连接数据库，连接后调用命令，这就是实践的过程。1. 引入 readies 的模块2. 实例对象3. 创建链接4. 调用命令 1.引入 readies 的模块调用 require, 先定义一个局部变量局部变量名为 importRedis，等于引入的外部redis, 跟的是文件名称，文件名称为 redis.lua，不能加 .lua 只能把 redis 写过来，但是不能仅仅写 redis, 因为 redis 目录在 use/local/Openresty/lualip/resty 中，Openresty 引入第三方的包使用时默认放在 resty 目录中，类似于 java 大数据环境中这些软件 jar 包，jar 包都在 lib下面，这个里面依赖的包 lualib 的 resty 中，系统在找的时候 Java/ 大数据中默认到 lib 中找，Openresty 默认到 lualob 中找，要想让他找到 redis.lua 首先要将默认到了的目录找到也就是 luaredis 目录的文件，还要将 resty 加到里面去。也就是在引入时需要引入的是 resty.redis 系统会默认它到 lualib 找，找到 resty, 去 resty 中去找 redis。所以这里先写 resty 目录再写, redis 文件名这一步就将 redis 引入了 local importRedis＝require"resty.redis"2.实例化对象定义一个 local 名为 redis,importRedis 是前面引入进来的，相当于已经拿到了redis, 引入以后直接调用，redis 实例化方法 _M.new, 可能有的同学有疑问前面进行调用直接 _M..new 通过这个方法来调用，但是这里需要先引进来用 local 接收，接收以后再调用时需要用到: importRedis:new(), 这个时候不需要 _M，可以省略掉，直接用对象变量:加上 new 就可以引过来，实例化以后就赋给了 redis。也就是说此 redis 拿到了实例，只不过变量名叫 redis, 这就是实例化 redis ，local redis=importRedis:new()3.创建连接创建连接实际上用 redis 去连接，依然是 _M.connect, 连接就要有一个 ip, 在这个服务器上 ip 是192.168.100.160，端口有三个打开 redis 有160.7001、160.7002、160.7003，现在的数据 heima 在7002中，这是 redis 在160上部署的一个集群，通过到这个节点上找这个端口去连接这就和节点连接上了，但是连接有可能连接成功也有可能连接失败，所以再来做一个局部接收，成功就用 ok 失败就用 err, 用 ok 和 err 进行接收连接时的一些信息，如果不成功就 then 输出连接失败，否则输出连接成功。 local ok , err =redis : connect (”192.168.100.160＂,7002)if not ok then ngx . say (＂ redis connect err ＂, err ) else ngx . say (＂ redis connect ok ”, Ok ) endfunctionM . connect (self ·)LocalSockTaWget(self,＂ sock ＂)if not sock then return nil ,＂ not inicialized＂ end self_ SubsCribed = falsereturn sock: connect (..) end function _ M . set _ keepalive ( self ,local sock rawget ( self ,＂_ sock ＂)if not sock then retarn nil ,＂ not initialized ”end 4.调用命令现在数据中有一个 heima 值是 verygood, 直接调用 redis,key 是 heima, 获取数据也有可能成功和失败。这就是 redis 读取数据的实例local ok , err =redis : get (”heima＂)if not ok then ngx . say (＂ get redis data＂, err ) else ngx . say (＂get redis data ”, Ok ) end 三、 运行代码如果代码有效果看看能不能优化，报错查看一下有哪些错误，接下来就把写好的脚本引入实例连接以后在调用，将脚本保存，保存以后上传到 testlua 里，上传以后脚本有了，但是还没有修改 nginx 配置文件，把名称由 content _ by _lua_ file usr /1ocal/ openresty / testlua / Test10 .lua; 改为 content _ by _lua_ file usr /1ocal/ openresty / testlua / TestRedis .lua;，路径还是这个路径只是名词变了，保存以后要生效看到效果就要重启 niginx 服务器重启没有报错，立刻回到首界面中刷新界面，如果正常没错的话就有 heima 正常输出出来，如果报错会给一个 err, 刷新过后显示如下结果，这个值不太好看，稍加处理一下，前面代码每次输出都加一个回车换行，保存后再次上传，上传不会覆盖将前面删掉，重启 nginx 服务器，刷新界面，这下可以看到换行了，先做是连接 redis，如果连接成功就报 OK，后面给了一个 ok 的值 OK 的值是1，获取数据get redis dataOK，读到了这个数据的值 verygood, 也就是heima 对应的是 verygood, 这就将 redis 中的数据读取出来了，这个流程走通就说明 redis 读取数据流程走通了读到了脚本里面。更改后的代码如下local ok , err =redis : connect (”192.168.100.160＂,7002)if not ok then ngx . say (＂ redis connect err ＂, err ) elesngx . say (＂ redis connect ok ”, Ok )ngx.say("＜br＞")endlocal ok , err =redis : get (”heima＂)if not ok then ngx . say (＂ get redis data＂, err ) ngx.say("＜br＞")else ngx . say (＂get redis data ”, Ok )end5. 注意当前的 redis 里面没有设置密码所以没有加这个，如果 redis 里面设置了密码还需要这一步操作，就可以读取数据了﹣请注意这里 auth 的调用过程local count count , err = red : get _ reused _times0if0= count then ok , err = red : auth (＂ admin ＂) if not ok then gx . say (" failed to auth :＂, err )return end elseif err thenngr . say (" failed to get reused times :＂ I , err )return end四、总结以上就是 redis 读取数据的过程，就是按上面四个步骤进行书写的。1.引入 readies 的模块local importRedis＝require"resty.redis"2.实例对象local redis=importRedis:new()3.创建链接local ok , err =redis : connect (”192.168.100.160＂,7002)4．调用命令local ok , err =redis : get (”heima＂)
-
发表了文章 2022-11-16
Lua 获取 Header 与 Body 数据｜学习笔记
开发者学堂课程【大数据实战项目：反爬虫系统（Lua+Spark+Redis+Hadoop 框架搭建）第一阶段：Lua 获取 Header 与 Body 数据】学习笔记，与课程紧密联系，让用户快速学习知识。 课程地址：https://developer.aliyun.com/learning/course/669/detail/11608Lua 获取 Header 与 Body 数据 内容介绍一．获取 header二．获取 body三．总结 一．获取 header--获取 headerlocal headers=ngx.req.get_headers() for k,v in pairs (headers) dongx.say("[header] name:", k," v: ", v) ngx.say("")end打开test10，写代码：保存，然后重启 nginx。服务器查看页面：以上就是 header 信息的获取。 二．获取 body--获取 body 信息local data = ngx.req.get_body_data()ngx.say(data)打开写好的脚本 test10：保存，重启 nginx，看效果：把请求方法改成 post请求主体改成 WANGWU。以上就是 body 信息的获取。 三．总结1.获取 header 的信息ngx.req.get_headers()2.获取 body 的信息（1）解析 body:ngx.reg.read_body)（2）获取: ngx.req.get_body_data()
-
发表了文章 2022-11-16
Lua 获取 Get 与 Post 请求数据｜学习笔记
开发者学堂课程【大数据实战项目：反爬虫系统（Lua+Spark+Redis+Hadoop 框架搭建）第一阶段：Lua 获取 Get 与 Post 请求数据】学习笔记，与课程紧密联系，让用户快速学习知识。 课程地址：https://developer.aliyun.com/learning/course/669/detail/11607Lua 获取 Get 与 Post 请求数据 内容介绍一． 获取 uri 参数二．总结 目前为止，openresty 里面的 index 和 lua 在前面已经集成完毕，只需要在 lua 的脚本当中写数据采集的代码就可以了，那么应该如何采集数据呢？用户在查询的时候都要通过一个 web 界面查询，web 界面走的协议是 HTTP协议。HTTP 协议有采集的数据在里面传输，是通过 HTTP 的请求采集过来的。 HTTP 的请求数据有 get 方式和 post 方式。 一． 获取 uri 参数获取一个 uri 有两个方法:ngx.req.get_uri_args、ngx.req.get_post_args，二者主要的区别是参数来源有区别代 table 元素的 (pairs)，迭代数组元素的 (ipairs )1.首先看 get 方式：--获取 get 请求参数Local arg=ngx.req.get _uri_ args()for k,v in pairs(arg) do ngx.say("[GET ] key:",k, " v:", v) ngx.say("<br>") end 用灰色部分就能够获取到前端用户请求的数据，请求的方式以及数据的一些参数，然后做接收，前面 local 定义局部，然后把相应的结果做 for 循环，然后输出。刚刚配置好的文件在 test10 里：前面写好的把他注释掉。写完之后保存，为了让它生效，虽然没有修改配置文件，但是脚本修改了，所以需要重启 nginx。重启没有报错，那么接下来刷新一下界面，界面是空的。原因是没有给参数，输入就可以了：以上就是通过 lua 脚本的方式实现了一个 Nginx 的 get 方式请求的数据的获取参数，然后做 for 循环的输出，然后输出 key。2.下面来看 post 方式:--获取 post 请求时 请求参数ngx. req.read_body()--解析 body 参数之前一定要先读取 body local arg=ngx.req.get_post_args()for k,v in pairs(arg) dongx.say("[POST] key:",k, " v:", v) ngx.say("<br>") end 同样先来写一下代码保存，重启 nginx刷新界面，看一下效果：我们需要在获取 post 数据前先要解析数据啊，怎么解析呢？在这执行之前输入 ngx. req.read_body()：保存，退出。再重启 nginx，界面是这样的：方法由 get 改成 post：请求主题改成 name=LISI点击发送:二．总结目标:掌握 Lua 获取 http 请求参数的用法获取 url 的请求参数get 方式的请求参数:ngx.reg.get_uri_args()，返回值是数组，需要遍历 post 方式的请求参数:(1)、解析 body:ngx.reqread_body()(2)、获取: ngx.reqget_post_args()
-
发表了文章 2022-11-16
Execvp 函数｜学习笔记
开发者学堂课程【物联网开发- Linux 高级程序设计全套视频：Execvp 函数】学习笔记，与课程紧密联系，让用户快速学习知识。 课程地址：https://developer.aliyun.com/learning/course/660/detail/11001Execvp 函数 Execvp 函数int execvp(const char *filename,char *const argv[]);第一个参数不传路径，直接传入可执行程序的文件名，会在默认路径下去寻找；第二个依然是一个指针数组，数组当中存放可执行程序的参数。代码示例：Execvp 第一个参数是默认路径下的文件名。如果 execvp 执行成功是不会执行之后的printf 语句 #include<stdio.h>#include<unistd.h>Int main(int argc ,char *argv[]){Char *arg[]={”ls”,”-a”,”-l”,”-h”,NULL};execv(“ls”，arg);printf(“after execvp\n”);return 0;}输入语句gcc esecvp.c -o execvp ./execvp运行结果启动这个程序必须实在默认路径下的内容。
-
发表了文章 2022-11-15
Map 的删除操作 | 学习笔记
开发者学堂课程【Scala 核心编程 - 进阶：Map 的删除操作】学习笔记，与课程紧密连接，让用户快速学习知识。课程地址：https://developer.aliyun.com/learning/course/610/detail/9042Map 的删除操作内容介绍：一、更新 map 的元素二、添加 map 方式三、删除 map 元素一、更新 map 的元素1.代码演示：val map5= mutable.Map((“A”,1),(“B”,”北京”),(“C”,3))map5(“AA”) = 20 //因为 AA 不存在，所以相当于添加println(“map5=”+map5)运行结果为：map5=Map(A->1,AA->20,C->3,B->北京)如果给的 key 是存在的，如下：val map5= mutable.Map((“A”,1),(“B”,”北京”),(“C”,3))map5(“A”) = 20 println(“map5=”+map5)运行结果为：map5=Map(A->20, C->3,B->北京)这就实现了 A 的更新（ map 把更新和添加融合在一起）2.说明：（1）map 是可变的，才能修改，否则报错。（2）如果 key 存在：则修改对应的值，key 不存在，等价于添加一个 key-val.类似于在 mysql 数据库中的学习，语句：sql = “delete from 表 where id =100”，假如这个 id 存在，就删除，假如不存在，也不报错，不产生影响。二、添加 map 方式1.方式一-增加单个元素val map5= mutable.Map((“A”,1),(“B”,”北京”),(“C”,3))map4+=(“D”->4)map4+=(“B”->50)println(map4)添加时， key 是存在，这时相当于更新,下面是代码的实现：val map5= mutable.Map((“A”,1),(“B”,”北京”),(“C”,3))map5+=(“A”->100)println(“map5=”+map5)运行结果为：map5=Map(A->100, C->3,B->北京)2.方式二-增加多个元素val map5= mutable.Map((“A”,1),(“B”,”北京”),(“C”,3))val map5=map4+(“E”->1,”F”->3)map4+=(“EE”->1,”FF”->3)说明：当添加一个 key-value ，如果 key 存在就是更新，如果不存在，则是添加。三、删除 map 元素1.重要代码：val map5= mutable.Map((“A”,1),(“B”,”北京”),(“C”,3))map5(“A”) = 20 map5+=(“A”->100)map5-=(“A”,”B”)//注意：map5-=(“A”,”B”)不等价于 map5=map5-(“A”,”B”)//-=的底层做了一系列的包装，有方法，不能简单的理解为赋值println(“map5=”+map5)运行结果：map5=(C->3)如果添加了一个不存在的 key，也不会报错，将上面的 map5-=(“A”,”B”) 改为 map5-=(“A”,”B”，“AAA”)，运行结果为：map5=(C->3)，没有异常抛出2.说明：（1）“A”，“B” 就是要删除的 key ，可以写多个（2）如果 key 存在，就删除，如果 key 不存在，也不会报错
-
发表了文章 2022-11-15
Map 的四种取值方式 | 学习笔记
开发者学堂课程【Scala 核心编程 - 进阶：Map 的四种取值方式】学习笔记，与课程紧密连接，让用户快速学习知识。课程地址：https://developer.aliyun.com/learning/course/610/detail/9041Map 的四种取值方式内容介绍：一、使用 map(key)二、使用 contains 方法检查是否存在 key三、使用 map.get(key).get 取值四、使用 map4.getOrElse() 取值五、如何选择取值方式建议一、使用 map(key)1.实例：val value1=map(“Alice”)println(value1)2.演示：以 map4为例（部分代码）：val map4 = mutable.Map(("Alice",10),("Bob",20), ("Kotlin",”北京”))println(map1(“Alice”)) //输出结果为10println(map4(“Alice~”)) //抛出异常3.说明（1）key 存在，则返回值对应的值（2）如果 key 不存在，则抛出异常[java.util.NoSuchElementException]（3）在 Java 中，如果 key 不存在则返回 null4.缺点对用户来说，看不懂的异常直接出现在屏幕上会产生不好的体验。没有防护机制，并且直接抛出异常容易暴露内部信息，造成攻击。异常信息不能直接暴露出来，所以下面的方式可以避免该问题。二、使用 contains 方法检查是否存在 key1.实例（重要代码）（1）val map4 = mutable.Map(("Alice",10),("Bob",20), ("Kotlin",”北京”))if (map4.contains(“Alice~”)){//注意：取值的方法不管是可变还是不可变都是一样的println(“key 存在，值=”+map4(“Alice~”))}else{println(“ key 不存在”)运行结果：key 不存在（2）val map4 = mutable.Map(("Alice",10),("Bob",20), ("Kotlin",”北京”))if (map4.contains(“Alice”)){//注意：取值的方法不管是可变还是不可变都是一样的println(“key 存在，值=”+map4(“Alice~”))}else{println(“ key 不存在”)运行结果：key 不存，值=102.返回值返回 Boolean（1）如果 key 存在，则返回 true（2）如果 key 不存在，则返回 flase3.说明使用 contains 先判断再取值，可以防止异常，并加入相应的处理逻辑4.缺点：不够简洁5.改进思路例如，SpringMVC 中的标签，取出返回一个值，不取出返回返回一个默认值。三、使用 map.get(key).get 取值通过 映射 get(键) 这样的调用返回一个 Option 对象，要么是 Some，要么是 None（Some 是 Option 的一个子类）1.实例val map4 = mutable.Map(("Alice",10),("Bob",20), ("Kotlin",”北京”))println(map4.get(“Alice”))//返回的不是一个值，而是 Some ，Some 中可以包含该值运行结果为：Some(10)如果要取出具体的值，则可以用get，如下println(map4.get(“Alice”).get)运行结果为：10此时如果 key 不存在，会抛出异常，因为已经是 None ，无法再取出，所以会抛出异常，代码为：println(map4.get(“Alice~”).get)2.注意：如果 key 存在，map.get(key) 就会返回Some （值），然后 Some(值).get 就可以取出如果 key 不存在， map.get(key) 就会返回 None，此时不能再 map.get(key).get ，否则会抛出异常 Exception in thread "main" java.util.NosuchElementException: None.get四、使用 map4.getOrElse() 取值1.getOrElse 方法：def getOrElse[V1>:V] [key:k,default:=>V1]2.说明：（1）如果 key 存在,返回 key 对应的值。（2）如果 key 不存在，返回默认值。在 jav 有中底层有很多类似的操作。3.实例（主要代码）：（1）val map4 = mutable.Map(("Alice",10),("Bob",20), ("Kotlin",”北京”))println(map4. getOrElse(“Alice”,”默认的值鱼 <*)))><<”))运行结果：10（2）val map4 = mutable.Map(("Alice",10),("Bob",20), ("Kotlin",”北京”))println(map4. getOrElse(“Alice~”,”默认的值鱼 <*)))><<”))运行结果：默认的值鱼 <*)))><<此时，“Alice~”不存在，其底层相当于做了一个 else 的返回，说明该方法包裹了一个 if else，当不存在时，返回默认值。所以上面是一个不存在的 key，则会返回：默认的值 鱼 <*)))><<（推荐方式四，比较简洁）五、如何选择取值方式建议方法没有被淘汰，说明其还有可取之处1.如果我们确定 map 有 key ，则应当使用 map(key)。这样效率很高，因为确定 map 有 key ，所以没有含多余的东西，速度快2.如果我们不能确定 map 是否有 key ，而且有不同的业务逻辑，使用 map.contains() 先判断再加入逻辑。不同的业务逻辑，当 key 存在时如何，当 key 不存在时又如何，不是简单的返回一个默认值。3.如果只是两个简单的希望得到一个值，使用 map.getOrElse (“”) .比如，假设要连接一个 IP 地址，如果取不到就可以连接本地（非此及彼的情况下，这样更高效）
-
发表了文章 2022-11-13
技术点-阿里云视频点播 SDK（获取视频地址） | 学习笔记
开发者学堂课程【微服务+全栈在线教育实战项目演练（SpringCloud Alibaba+SpringBoot）：技术点-阿里云视频点播 SDK（获取视频地址）】学习笔记，与课程紧密连接，让用户快速学习知识。课程地址：https://developer.aliyun.com/learning/course/667/detail/11401技术点-阿里云视频点播 SDK（获取视频地址）目录：一、服务端与客户端二、获取视频的播放地址三、获取视频播放凭证四、上传视频到阿里云视频点播服务五、方法一、服务端与客户端（1）服务端：接口部分（Java 代码）API（提供固定地址）ADK（直接调用依赖，较常用）（2）客户端：调用部分（浏览器，安卓等）二、获取视频的播放地址（根据视频 id 获取到）点击视频管理，获取视频地址，在浏览器直接就可以播放视频，但经过加密的地址，在浏览器是不可以直接播放的，因此在在数据中不存储地址，而存储视频id。代码：接口参数和返回字段请参考 GetPlaynto.import com.aliyuncs.vod.model.v20170321.GetPlayInfoRequest;import com.aliyuncs.vod.model.v20170321.GetPlayInfoResponse;/*获取播放地址函数*/public static GetPlayInfoResponse getPlayInfo(DefaultAcsClientclient) throws Exception {GetPlayInfoRequest request = ner GetPlayInfoRequest();request.setVideoId("视频ID");return client.getAcsResponse(request);/*以下为调用示例*/public static void main(String[] argv) {DefaultAcsClientclient=initVodClient("<您的AccessKeyId>",”<您的AccessKeySecret>");GetPla yInfoResponse response new GetPlayInfoResponse();List GetPlayInfoResponse.PlayInfo> playInfolist.response.etPlayInfolist();//播放地址for (GetPlayInfoResponse.PlayInfo playInfo:playInfolist)System.out.print("PlayInfo.PlayURL=+ playInfo.getPlayURL()+"Xn");//Base信息.System.out.print("VideoBase.Title."+response.getVideoBase().getTitle()+"Xn");]catch (Exception e) System.out.print("ErrorMessage.."+e.getLocalizedMessage())System.out.print("RequestId."+response.getRequestId()+"In")三、获取视频播放凭证（根据视频id获取到） 拥有播放凭证既可播放不加密视频也可以播放加密视频，是一个许可证。代码：接口参数和返回字段请参考 GetVdeoPlayAuth.import com.aliyuncs.vod.model.v20170321.Get Vi deoPlayAuthRequest;import.com.aliyuncs.vod.model.v20170321.Get Vi deoPlayAuthResponse;/*获取播放凭证函数*/public static Get VideoPlayAuthResponse get Vi deoPlayAuth(DefaultAcsClient client) throws ExceGet VideoPlayAuthRequest request = ner GetvideoPlayAuthRequest();request.setVideoId("视频ID");return client.getAcsResponse(request);/*以下为调用示例*/public static void main(String[] argv) DefaultAcsClientclient-initvodClient("<您的AccessKeyId>","<您的AccessKeySecret>");GetVideoPlayAuthResponseresponse.new GetVideoPla yAuthResponse();try response = getVideoPlayAuth(client);//播放凭证System.out.print("PlayAuth-"+response.getPlayAuth()+"In");//VideoMeta信息System.out.print("VideoMeta.Title..+response.getVideoMeta().getTitle()+"In");catch (Exception e) System.out.print("ErrorMessage ="+e.getLocalizedMessage());System.out.print("RequestId"+response.getRequestId()+"Xn");四、上传视频到阿里云视频点播服务五、方法（1）在 service 创建子模块 service_vod，引入相关依赖，到01-视频点播微服务的创建笔记进行复制。依赖代码如下：<dependencies><dependency><groupId>com.aliyun</groupId>cartifactId>aliyun-java-sdk-core<fartifactId></dependency><dependency><groupId>com.aliyun.oss</groupId>cartifactId>aliyun-sdk-oss<lartifactId)</dependency><dependency)<groupId>com.aliyun</groupId><artifactId>aliyun-java-sdk-vod<fartifactId></dependency><dependency><groupId>com.aliyun</groupId><artifactId>aliyun-sdk-vod-upload</artifactId)</dependency><dependency><groupId>com.alibaba</groupId><artifactId>fastjson</artifactId)</dependency><dependency><groupId>orgjson</groupId> cartifactId>json</artifactId></dependency>(dependency)groupId>com.google.code.gson</groupId> cartifactId>gson</artifactId)</dependency><dependency><groupId>joda-time</groupId>cartifactId>joda-timec/artifactId></dependency></dependencies)（2）初始化操作，创建DefaultAcsClient对象public class InitObject{publicstaticDefaultAcsClientinitVodClient(String accessKeyld,String accessKeySecret)throws ClientException{String regionld="cn-shanghai";1点播服务接入区城DefaultProfile profile=DefaultProfile.getProfile(regionld,accessKeyld accessKeySecret):DefaultAcsClientclient=new DefaultAcsClient(profile); return client:}（3）实现根据视频id获取视频播放地址//根据视频 iD 获取视频播放地址//创建初始化对象DefaultAcsClient client=InitObject.initVodClient(accessKeyld:"LTAI4FvvVEWiTJ3GNJJqJnk7"accessKeySecret:"9st82dv7EvFk9mTjY01xxbM632fRbG”）//创建获取视频地址request和responseGetPlayInfoRequestrequest=newGetPlayInfoRequest() GetPlayInfoResponse response=newGetPlayInfoResponse()//向 request 对象里面设置视频 idrequest.setVideoId("474be24d43ad4f76af344b9f4daaabd1”）//调用初始化对象里面的方法，传递request,获取数据response=client.getAcsResponse(request);List<GetPlavInfoResponse.PlayInfo>playInfoList=response.getPlayInfoList()://播放地址for(GetPlayInfoResponse.PlayInfo playInfo:playInfoList){Systemoutprint("PlayInfo.PlayURL="+playInfo.getPlayURL()+"\n”)//Base信息System.outprint("VideoBase.Title="+response.getVideoBase().getTitle()+"\n”);运行结果："D:Program FilesJavaljdk1.8.0_181bin java.exe'PlayInfo.PlayURL = htto://videotest.xa-src.com/sv/48bb416a-170a0783597/48bb416a-170a0783597.mp4VideoBase.Title = 6-What If I Want to Move Faster.mp4Process finished with exit code 0
-
发表了文章 2022-11-13
技术点-SpringCloud 调用接口流程 | 学习笔记
开发者学堂课程【微服务+全栈在线教育实战项目演练（SpringCloud Alibaba+SpringBoot）：技术点-SpringCloud 调用接口流程】学习笔记，与课程紧密连接，让用户快速学习知识。课程地址：https://developer.aliyun.com/learning/course/667/detail/11421技术点-SpringCloud 调用接口流程内容介绍一、Hystrix 基本概念二、流程原理示意图一、Hystrix 基本概念SpringCloud 的另一个组件叫 Hystrix，或者叫断路器。1、Spring Cloud 调用接口过程Spring Cloud 在接口调用上，大致会经过如下几个组件配合：Feign——>Bystriz—>Ribbon—> HttpClient ( apache http components或者OKhttp).二、流程原理示意图过程中会遇到Feign——>Bystriz—>Ribbon—> HttpClient ( apache http components或者OKhttp)这几个组件，这几个组件相互配合，才会实现之前的效果。在调用过程中有两部分，一个叫调用端，一个叫被调用端，说的官方一点，一个叫消费者，另一个是生产者。首先说消费者，因为这个过程都是在消费中做到。首先第一步叫接口化请求调用，这句话说的比较官方，说的通俗一点其实很好理解，比如说vod里边指定了接口位置，也指定了接口地址，就是你设置一下调用的服务和服务中的那个调用方法，这就是第一步，比如现在调用 service vod 中的 eduvod video removeAlVideo {id}，第一步就是在里边定义。接下来第二步就是 Feign 组件，在第一步时候只是做到了定义并没有真正意义上的调用，而真正调用的过程就是在第二步之后执行的，而 Feign 要做的事情就是首先在方法里找到具体位置，用方法调用功能，但是它要远程调用 service voc，Feign就去找到 service voc 定义的名字，找到位置并调用。根据名字找到服务做调用，这个过程叫 Feign，这就是第二步。第三步也就是接下来要用的组件 Hystrix，它的名字叫熔断器或者叫断路器。比如说vod的服务器突然挂掉了，要是再去调就调不到了，然后就要直接给它断掉，如果没有挂掉就直接调用，如果挂掉了就直接断掉，这就是所说的熔断器或者断路器，就是做到系统的一种保护功能。如果能调用就直接跳过熔断到下一步，叫 Ribbon，它的含义是，比如现在熔断可以成功调用，那下一个就肯定要调服务组件，这个 Ribbon 组件就是负载均衡，负载均衡就是，比如说现在把 vod 配置到多个服务器，那现在 Ribbon 就会将这些分布到集群服务器中，假如现在有两个服务器，就会把请求平均分到两台服务器中，这就叫负载均衡，用 Ribbon 来做到。当负载均衡也做到之后，最后一步就是做真正的调用，而最终调用就是用 HttpClient ，这个就是真正用端口去服务方法的一个效果。总体：首先有一个消费者做调用，最后有一个生产者做调用，生产者也可以叫被调用者，第一步就是接口化请求调用，就是找到接口的位置和地址，第二步就是根据名字找到服务中的接口做调用，第三个就是比如生产者的服务器当机了就用熔断机制，让它不再调用，如果服务器没挂掉，就正常往下走，一种保护功能。如果能正常调用就到下一步，就是对你的请求做负载均衡，比如现在生产者有一个集群，但是它会把调用的分担到不同的服务器中，分担之后，就是发送请求，就是最终执行被得到。
-
发表了文章 2022-11-13
根据 token 获取用户信息（接口） | 学习笔记
开发者学堂课程【微服务+全栈在线教育实战项目演练（SpringCloud Alibaba+SpringBoot）：根据 token 获取用户信息（接口）】学习笔记，与课程紧密连接，让用户快速学习知识。课程地址：https://developer.aliyun.com/learning/course/667/detail/11450根据 token 获取用户信息（接口）内容介绍：一、在 MemberApiController 中创建方法二、创建 service三、创建接口一、在 MemberApiController 中创建方法@ApiOperation (value -“根据token获职登录信息")@GetMapping("" auth/getLoginInfo")public R getLoginInfo(HttpServletRequest request){try {StringmemberId-JwtUtils. getMemberIdByJwtToken(request);LoginInfoVo loginInfoVo - memberService.getLoginInfo(memberId);return R.ok () . data(""item” ,loginInfoVo);}catch(Exception e){e .printStackTrace(;thraw new GuliException(28001,""error");}}二、创建 service@Overridepublic LoginInfovo getLoginInfo(String memberId) {Member member - bas eMlapper.selectById(memberId);LoginInfovo loginInfovo - new LoginInfoVo（）;Beanutils .copyProperties (member，loginInfovo);return loglnInfoVo;}三、创建接口登录过后生成的 token 数据字符串，字符串中包含用户信息，这一串数据要通过路径返回到前端页面上。接口的目的就是根据 token 字符串得到用户数据，并在前端页面显示。//根据 token 获取用户信息GetMapping("getMemberInfo")//传入request对象public R getMemberInfo(HttpServletRequest request){//调用jwt工县类的方法。根据request对象获取头信息，返回用户id StringmemberId= JwtUtils.getMemberidByJwtToken(request) ;//查询数据库根据用户id获取用户信息UcenterMembermember=memberService. getById(memberId); return R.ok( . data("userInfo" , member) ;}
-
发表了文章 2022-11-12
配置镜像加速器｜学习笔记
开发者学堂课程【深入解析 Docker 容器化技术：配置镜像加速器】学习笔记，与课程紧密联系，让用户快速学习知识。课程地址：https://developer.aliyun.com/learning/course/659/detail/10936配置镜像加速器 内容介绍一、前言二、演示配置镜像加速器 一、前言在上节课程中已经学习了命令 docker pull 拉取镜像，而在拉取镜像的过程当中，访问的服务器是 docker hub 镜像仓库，那么在访问或者拉取过程中，有可能出现拉取速率比较慢，所以为了解决速率慢的问题，可以去配置镜像加速器，下面开始进行配置镜像加速器的讲解。在资料的拉取镜像中提供了镜像加速器的配置，也就是如果拉取这个镜像速率比较慢，是可以配置镜像加速器的。资料中提到的镜像加速器有阿里云(先加入阿里云开发者平台: https://dev.aliyun. com)，docker 中国加速器(https ://www. docker-cn. com)，USTC 加速器(https://lug. ustc.edu.cn/wiki/ )，还有国内的 daocloud 以及网易蜂巢加速器等，那么在这个过程当中只演示一个，其他的可以参考官方文档去配置，下面开始演示如何使用阿里云去配置镜像加速器。 二、演示配置镜像加速器首先打开阿里云网站进行登录，没有账号的需要注册后登录，登录后可以看到主页左边的目录和菜单，打开弹性计算目录找到容器镜像服务，如图：点击进入页面后，选择管理控制台，进入控制台后在左边目录中可以找到镜像加速器，点入如图：可以看到镜像加速器页面中也有如何去进行配置的操作文档，本次演示中用到的是 CentOS，所以这里选择 CentOS 的配置操作文档，如图：注意在这个过程当中要对/etc/docker/路径下的 daemon.json 文件进行编辑，而如果没有这个文件的话就需要去创建一个，下面进行编辑这个文件，进入文件如：[root@localgost ~]#vim etc/docker/daemon.json拷贝到文件中如下内容：{“registry-mirrors”: [“https://cs913o6k.mirror.aliyuncs.com”]}registry 为指定镜像 keyvalue，mirrors 为指定镜像仓库，[ ]中的为具体的镜像加速器地址，然后保存退出。退出后还需要重启 docker，首先要执行重新加载配置指令 systemctl daemon-reload，然后执行命令systemctl restart docker 进行重启 docker，如：[root@localgost ~]#systemctl daemon-reload[root@localgost ~]#systemctl restart docker重启后再次拉取镜像查看速率有没有变化，此处拉取镜像为 ubuntu，如：[root@localgost ~]#docker pull ubuntu从拉取镜像的过程中能感觉得到速率确实是比之前快。此时查看镜像可以看到 ubuntu 镜像，如：[root@localhost ~]# docker imagesREPOSITORY TAG IMAGE ID CRATED SIZEubuntu latest 2ca708c1c9cc 6 hours ago 64.2MBcentos latest 67fa590cfc1c 4 weeks ago 200MB所以如果出现拉取镜像较慢的情况时可以配置镜像加速器进行提速。
-
发表了文章 2022-11-12
拉取镜像｜学习笔记
开发者学堂课程【深入解析 Docker 容器化技术：拉取镜像】学习笔记，与课程紧密联系，让用户快速学习知识。课程地址：https://developer.aliyun.com/learning/course/659/detail/10935拉取镜像 拉取镜像在之前列出镜像后发现本地并没有所需镜像，那么参考之前讲过的 C/S 架构图，图上说明如果本地没有镜像可以从镜像仓库拉取所需镜像，如图：从仓库中拉取镜像要使用 pull 命令。要拉取 centos 镜像，这里需要注意如果在拉取过程中指定版本号，是冒号加上指定版本号即可，如：[root@localhost ~]#docker pull centos:version如果不指定版本，那么拉取的就是最新的版本，如：[root@localhost ~]#docker pull centosUsing default tag: latestlatest: Pulling from library/centos在此过程中 Pulling fs layer 为正在拉取，如：d8d02d457314: Pulling fs layerDownloading 为正在下载，并且可查看到镜像大小，此处镜像大小为75.41MB，如：d8d02d457314: Downloading[====> ] 5.872MB/75.41MBExtracting 为正在解压，如：d8d02d457314: Extracting[===> ]67.4MB/75.41MB拉取镜像成功，如：[root@localhost ~]# docker pull centosusing default tag: latest latest: Pulling from library/centosd8d02d457314: Pull completeDigest: sha256:307835C385f656ec2e2fec602cf093224173c51119bbebd602c 53C3653a3d6ebstatus: Downloaded newer image for centos: latestdocker. io/library/centos: latest此时再查看本地镜像如下：[root@localhost ~]# docker imagesREPOSITORY TAG IMAGE ID CRATED SIZEcentos latest 67fa590cfc1c 4 weeks ago 200MB可以查看到在本地已经有一个镜像 centos，为最新版latest，镜像 ID 为67fa590cfc1c，镜像创建日期为4 weeks ago，解压后的大小为202MB。
-
发表了文章 2022-11-12
Nacos 配置中心（多配置文件加载1） | 学习笔记
开发者学堂课程【微服务+全栈在线教育实战项目演练（SpringCloud Alibaba+SpringBoot）：Nacos 配置中心（多配置文件加载1）】学习笔记，与课程紧密连接，让用户快速学习知识。课程地址：https://developer.aliyun.com/learning/course/667/detail/11541Nacos 配置中心（多配置文件加载1）Nacos 配置中心（加载多个配置文件）在实际项目中，以 application.properties 为例，其中就很多配置，现在可以分为多个文件，在 nacos 支持读取多个文件。1、在 dev 命名空间创建两个配置文件在 dev 中有个配置文件，将其端口号去除，在 dev 中创建其他配置文件:port.properties,配置格式为 properties，将端口号写到新创建的文件，进行发布，返回到 dev 中有两个配置文件，port 中有端口号。2、修改项目中的配置文件，记载 nacos 多个配置文件，只有1个配置文件就写0，若有多个配置文件就按照编号写。#该配置影响统一配置中心中的 dataIdspring. application. name=service-statisticsspring.cloud. nacos.config.namespace=fffcbc78-504b-4cae-b9a2-3f50eOc2c4efspring.cloud.nacos.config.ext-config[o].data-id=rddis. Properties#开启动态刷新配置，否则配置文件修改，工程无法感知spring.cloud. nacos.config.ext-config[0].refresh=true加上配置文件的配置名称 spring. cloud. nacos.config.ext-config[o].data-id=prot. Properties。重新启动，有点小问题，端口号读取的不是修改的端口号，修改端口号为8444，确认发布，没有变化。
-
发表了文章 2022-11-12
Nacos 配置中心（命名空间切换） | 学习笔记
开发者学堂课程【微服务+全栈在线教育实战项目演练（SpringCloud Alibaba+SpringBoot）：Nacos 配置中心（命名空间切换）】学习笔记，与课程紧密连接，让用户快速学习知识。课程地址：https://developer.aliyun.com/learning/course/667/detail/11540Nacos 配置中心（命名空间切换）内容介绍：一、命名空间切换环境二、名称空间切换环境过程一、命名空间切换环境在实际开发中，通常有多套不同的环境（默认只有 public )，那么这个时候可以根据指定的环境来创建不同的 namespce，例如，开发、测试和生产三个不同的环境，那么使用一套 nacos 集群可以分别建以下三个不同的 namespace。以此来实现多环境的隔离。打开 nacos，方框中 public 为名称空间，这是一个默认的包。项目有几种开发环境 dev、test、prodDev 为开发环境，Tes 为测试环境，Prod 为生产环境，一般来说，在实际生产中，每个开发文件的应用环境都有区别，dev 应用的一般为本地的数据库，测试环境就是指一个项目已经设计完毕，项目齐全，给他打包放置于一个环境中，进行各种测试，测试没有问题就能够上解密行，测试环境就应用的不是本地环境，应用的是一个测试环境；项目测试成功之后就会上线给用户应用，这个数据库就是最正规的数据库。在 nacos 中有个数据描述，这个词就叫做命名空间。默认空间为 public，也可以新建一些空间，然后通过此配置文件可以读取不同命名空间的配置文件，这就叫做名称空间切换环境。二、名称空间切换环境过程1、在 nacos 默认空间命名空间在里面也可以创建多个空间，点击命名空间，点击新建空间，分别创建dev，开发环境；test,测试环境；prod，生产环境；2、在不同名称空间创建配置文件在名称空间有个id，先在不同的命名环境进行名称创建进行测试，点击左侧配置列表，就列出了当前有的配置文件，现在有四个配置文件：public、test、prod、dev。第一种方法：点击加号，在里面进行配置第二种方法：使用克隆方式进行创建选择配置文件，点击克隆，对他进行复制，就会弹出克隆配置，有个原空间，以及目标空间，现在选择复制到 dev 中，然后点击开始克隆。点击 dev，发现此文件就已经复制过来了，3.最终读取需要新添加一些配置文件，需要加上namespace，值就加上默认的对应的值，为了易于区分，将端口号改为9999（1）修改配置文件，添加命名空间#配置中心地址spring.cloud. nacos. config.server-addr=127.0.0.1:8848spring. profiles.active=dev#该配置影响统一配置中心中的 dataIdspring. application. name=service-statisticsspring.cloud.nacos.config. namespace=13b5c197-de5b-47e7-9903-ec0538c9dbo1在里面可以创建多个配置文件，然后可以在里面添加文件，值修改为名称空间里的id值，最后开始测试，启动成功，端口号为新的端口号。
-
发表了文章 2022-11-12
Nacos 配置中心（读取配置文件） | 学习笔记
开发者学堂课程【微服务+全栈在线教育实战项目演练（SpringCloud Alibaba+SpringBoot）：Nacos 配置中心（读取配置文件）】学习笔记，与课程紧密连接，让用户快速学习知识。课程地址：https://developer.aliyun.com/learning/course/667/detail/11539Nacos 配置中心（读取配置文件）内容介绍：一、Nacos 配置中心（读取配置中心配置文件）二、方法二一、Nacos 配置中心（读取配置中心配置文件）1、做法就是先点击配置列表，再点击右边的加号，2、进入这个页面之后要填写读取的配置文件的名称，第二个是配置文件的默认组，第三个是配置文件内容和配置格式Data ID的完整规则格式如下$ {prefix}-$ {spring. profile. active}. ${file-extension}- prefix 默认为所属工程配置 spring. application. name 的值(即: nacos- provider ) , 也可以通过配置项 spr ing. cloud. nacos. config. prefix 来配置。——服务名称- spring. profiles. active=dev 即为 当前环境对应的profile。注意: 当spring. profiles. active 为空时，对应的连接符-也将不存在, dataId的拼接格式变成$ {prefix}. ${file-extension}——dev 的值- file-exetension 为配置内容的数据格式，可以通过配置项spring. cloud. nacos. config. file-extension 来配置。目前只支持 properties 和yaml 类型。——配置文件类型创建完成后点击确定弹出配置信息可能有错误是否忽略点击确定，创建完成后不会自动跳转，需要手动点击配置列表，显示编辑的配置文件，此时点击编辑之后data id 则无法修改，可以删掉重新配置，但是不能修改，创建完成后进行测试查看如何进行测试。3、在项目中读取 nacos 配置中心文件（1）springboot 配置文件加载顺序之前见到的配置文件都是 application 等等，其实 yml 和 properties 文件是一样的原理，且一个项目上要么yml或者properties，二选一的存在。推荐使用 ymI,更简洁。bootstrap 与 application.加载顺序这里主要是说明 application 和 bootstrap 的加载顺序。bootstrap. yml < bootstrap.properties) 先加载application. ym| bootstrap. yml 用于应用程序上下文的引导阶段。bootstrap. yml 由父 Spring ApplicationContext 加载。父 ApplicationContext 被加载到使用 application.yml 的之前。(2)配置区别bootstrap. yml 和 application. yml 都可以用来配置参数。bootstrap. yml 可以理解成系统级别的一-些参数配置， 这些参数- -般是不会 变动的。application. yml 可以用来定义应用级别的。当启用 springboot 时第一个加载bookstore这个文件，第二个运行的是application，假如加了 spring.profiles.active=dev 这句话就运行第三个文件application_dev(3) 创建 bootstrap-properties 文件创建 bootstrap-properties 文件,先将其中的内容注释掉，然后添加下述配置#配置中心地址spring.cloud.nacos . config.server- addr=127.0.0.1:8848#spring. profiles . active=dev#该配置影响统一配置中心中的 dataId spring. application.name-service-statistics4、调用的服务里面引入 config 依赖在配置中心还需要引入一个依赖，org. springfr amework . cloudspring-cloud-starter-alibaba-nacos -config测试Application 中什么都没有，所以启动的时候就读取8999这个文件。@SpringBootApplicationgomponentScan (basePackages = {" com. atguigu"})@EnableDiscoveryClient@EnableFeignClients@MapperScan (' com. atguigu. staservice. mapper' )@CEnableSchedulingpublic class StaApplication {public static void main(String[] args) { SpringApplicat ion. run(StaApplication. class, args) ;启动后发现端口号时8999，证明配置文件读到了远程的nacos中的文件二、方法二1、修改项目 bookstrap.properties 配置文件，添加一行配置#配置中心地址spring. cloud. nacos. config. server addr-127. 0.0.1:8848spring. profiles. active=dev#该配置影响统一-配置中心中的 dataIdspr ing. appl ication. name= service statistics2、当配置文件添加上面那行配置之后，之前创建配置文件读取不到了，需要按照新的规则创建配置文件，就是修改名字，将配置文件修改为 service-statistics-dev-properties,将文件内容复制过来并且修改端口号为8111，重新启动，查看端口号，段就好为8111.3.启动项目查看新创建的项目文件
-
发表了文章 2022-11-12
阿里云镜像仓库使用｜学习笔记
开发者学堂课程【深入解析 Docker 容器化技术：阿里云镜像仓库使用】学习笔记，与课程紧密联系，让用户快速学习知识。课程地址：https://developer.aliyun.com/learning/course/659/detail/10953阿里云镜像仓库使用 内容介绍一、创建镜像仓库二、镜像仓库的具体使用 一、创建镜像仓库除了可以使用 Dockerhub 仓库还可以直接使用阿里云镜像仓库。把镜像推送到阿里云上：进入阿里云官网，注册账号，找到操作文档容器镜像服务，进入容器镜像服务的管理控制台。1、创建命名空间创建镜像仓库需要一个命名空间，如果是首次创建则需要首先创立一个命名空间。创建命名空间的要求：定义镜像仓库命名空间，设置后不可修改，长度为2-30位,可填写小与英交字母，数字，可使用的分隔符包括“_”，“-”（分隔符不能在首位或末位）。这里命名空间为 itheima_task。这样就创建好了命名空间。2、创建镜像仓库设置仓库信息，地域为华东1（杭州），命名空间为 itheima_task，仓库名称是 itheima_repo，仓库类型可以设置为公开或者私有，这里设置为私有，摘要为测试使用。点击下一步，在代码源中绑定账号，通过本地仓库将本地镜像推送到镜像仓库中。这样就创建好了镜像仓库。 二、镜像仓库的具体使用点击仓库//登录阿里云 Docker Registry，输入密码。该账号是提前注册好的账号，登录成功之后可以将本地仓库推送过来。sudo docker login --username-华南13区 registry.cn-hangzhou. aliyuncs.com//查看本地仓库docker images//对仓库的镜像设置标签，参考以下命令sudo docker tag [ImageId] registry.cn-hangzhou. aliyuncs.com/ itheima_task/itheima,repo:[镜像版本号]。以 rw_nginx 为例，镜像版本号是 v1。sudo docker tag rw_nginx registry.cn-hangzhou. aliyuncs.com/ itheima_task/itheina,repo:v1//查看效果docker images//推送镜像到阿里云仓库Sudo docker push registry.cn-hangzhou.aliyuncns.com/itheima_task/itheima_repo:v1该镜像大小为400多兆，所以推送时间较慢。推送完成：推送完之后可以通过阿里云查看镜像是否推送成功。查看镜像版本：该镜像就是刚刚推送到的镜像，版本是 V1 版本。对该镜像进行安全扫描，扫描之后生成报告显示低危漏洞，中危漏洞，高危漏洞和未评级漏洞分别有多少个。安全扫描的好处是检测镜像是否安全。
-
发表了文章 2022-11-12
Docker 引擎启动、停止、重启操作｜学习笔记
开发者学堂课程【深入解析 Docker 容器化技术：Docker 引擎启动、停止、重启操作】学习笔记，与课程紧密联系，让用户快速学习知识。课程地址：https://developer.aliyun.com/learning/course/659/detail/10931Docker 引擎启动、停止、重启操作 内容介绍一、 docker 启动二、 docker 停止三、 docker 重启 一、docker 启动启动 docker，可以查看 docker 的状态输入 systemct1 status docke输出：docker. service一Docker Application Container Engine Loaded: loaded (/usr /1ib/syst emd/system/docker. service; disabled;vendor preset:disabledActive: active (running) since wed 2019-09-18 21:16:38 PDT; 1min 52s ago DOCS:https:/ , docs. docker. comMain PID: 2826 (dockerd)Memory: 142. 4MCGroup: /system. slice/docker . service2826/usr/bin/dockerd-Hfd://--containerd=/run/containerd/containerd.sock这里 docker 是运行起来的，控制台里也能看到 docker 在 centos 里开机默认是关闭的，也可以设置开始启动的。 二、docker 停止停止 docker输入：systemct1 stop docker 三、docker 重启重新启动 docker输入：systemct1 restart docker查询状态docker. service一Docker Application Container Engine Loaded: loaded (/usr /1ib/syst emd/system/docker. service; disabled;vendor preset:disabledActive: active (running) since wed 2019-09-18 21:19:38 PDT; 3s ago DOCS:https:/ , docs. docker. comMain PID: 3056 (dockerd)Memory: 43.7MCGroup: /system. slice/docker . service2826/usr/bin/dockerd-H fd:// -- containerd= /run/containerd/containerd.sock处于运行状态
-
发表了文章 2022-11-11
Canal 数据同步（应用场景） | 学习笔记
开发者学堂课程【微服务+全栈在线教育实战项目演练（SpringCloud Alibaba+SpringBoot）：Canal 数据同步（应用场景）】学习笔记，与课程紧密连接，让用户快速学习知识。课程地址：https://developer.aliyun.com/learning/course/667/detail/11515Canal 数据同步(应用场景)目录：一、canal 数据同步工具二、Canal 介绍一、canal 数据同步工具把远程库里面内容同步到本地库里面1、应用场景分库比如，现在两个模块，第一个模块叫 edu-sta。比如第二模块叫 edu-ucenter，就是用户模块。按照实际的操作中，经常会做一件事情分库的。分库的解释，比如现在在 edu-sta这是一个统计模块，那现在就可以把统计模块数据存到一个数据库，假如说统计模块，它的数据库就是这个叫 edu-sta 数据库，然后里边有数据库表，然后现在也是有一个数据库，它的数据库叫 edu-ucenter，做一个分库的处理，之前为了方便把所有表放到都放入一个库中，现在是每个模块专门建一个数据库，比如现在建一个模块叫 edu-sta，这数据库中专门存统计模块，又建一个数据库叫 edu-ucenter这数据库中专门存用户信息，现在有两个数据，在 ucenter 得到数据 STA 通过远程调用。有两个数据库，通过 edu-sta 这个库中调用 edu-ucenter 数据库内容。它的缺点，因为要调共同库里面，比如说实际项目中，项目比较大时，自身开发的sta数据库，另一家公司开发的 edu-ucenter 数据库，公司有自己数据库，那这个时候因为公司肯定不可能去，直接访问另一家数据库，所以必须要用远程调用才可以，这是一个场景，而这个过程是一个要让偶合度很高，第二个要调远程库，它的效率也并不是很高。解决方法是使用数据同步工具，举个例子，现在在 edu-ucenter 里面还有一张表，这个表比如叫 users，可以把这个表同步到中 edu-sta，就是同步 user 表，在 edu-sta 中可以创建一张跟这数据库中相同一样的表的结构，此时两边的数据可同步变化，比如一表中添加一条数据这边也会同步加入数据，这个数据进行了修改，另一边也会修改。也就是说远程库中的发生变化，本地库会跟着变化。那再操作可以直接操作本库，而就不需要再做远程调用过程。canal 是阿里巴巴旗下的一款开源项目，纯 Java 开发，目前支持 mySQL 数据库。举个例子，访问移动的数据库，想得到里面数据那怎么做呢？可以把移动数库中一些核心部分通过到本地库中，当它发生变化，那本地库也会跟着发生变化。这过程就叫数据同步，把远程同步到本地库中。这也称为数据同步。其实这个过程，更具体点，它是大数据中这种实验过程，但是在java中这个过程也会经常用到。canal 是阿里巴巴项目，它是用 JAVA 开发的，可以做到数据同步，目前只支持mysql 还不支持别的数据库。二、Canal介绍1、应用场景在前面的统计分析功能中，我们采取了服务调用获取统计数据，这样耦合度高，效率相对较低，目前我采职另一种实现方式，通过实时同步数据库表的方式实现，例如我们要统计每天注册与登录人数，我们只需把会员表同步到统计库中，实现本地统计就可以了，这样效率更高，耦合度更低，Canal 就是一个很好的数据库同步工具。canal 是阿里巴巴旗下的款开源项目，纯 Java 开发。 基于数据库增量日志解析，提供增量数据订阅&消费，目前主要支持了 MySQL。2、Canal 环境搭建canal 的原理是基于 mysql binlog 技术，所以这里-定需要开启 mysql 的 binlog 写入功能开启 mysqI 服务: service mysql start ( 或者 systemctl start mysqld.service )(1 )检查 binlog 功能是否有开启代码如下：mysql> shaw varlables like 'log_bin';+---------------+-------+| Variable _name | Value| +---------------+-------+| log_bin | OFF |+--------------+-------+
-
发表了文章 2022-11-11
Docker hub 镜像仓库使用｜学习笔记
开发者学堂课程【深入解析 Docker 容器化技术：Docker hub 镜像仓库使用】学习笔记，与课程紧密联系，让用户快速学习知识。课程地址：https://developer.aliyun.com/learning/course/659/detail/10952Docker hub 镜像仓库使用 内容介绍一、docker 仓库二、举例说明 一、docker 仓库本次进行对 docker 仓库的讲解。在之前讲的案例中是存在一些问题，比如162服务器当中有镜像 mytomcat，而163服务器也需要镜像 mytomcat，当时讲解的是通过scp 拷贝到163服务器，如果有100台服务器都需要 mytomcat 镜像，是不可能一台一台进行拷贝的，所以可以将 mytomcat 镜像放到仓库中，而其他的服务器需要镜像就从仓库中下载，与 Java 中 maven 仓库相同（需要 jar 包就根据仓库中拿取）。之前讲过镜像仓库默认是 docker hub，也讲过阿里云，docker hub 的话下载速度是比较慢的，因为服务器是在国外的，在实际开发中是使用阿里云，除此之外如果想省钱可以自己搭建私有仓库，下面进行 Docker hub 镜像仓库的讲解。可以将自己创建的镜像推送到 docker hub 当中，如果要将制作的镜像推送到docker hub 中，首先需要注册 docker hub，打开 docker hub 网站，在访问过程中可以感觉得到访问速度很慢，打开网站后注册账号进行创建仓库，注意在将镜像推送上来时要设置镜像的标签，否则推送不到仓库，网页创建仓库页面如下：右边蓝色文本框内说明了如何进行推送，第一步为对镜像设置标签，然后再执行docker push 进行推送。 二、举例说明这里举一个例子说明，如：docker tag local- image:tagname new-repo:tagname (设置tag)docker tag 进行设置镜像标签，image 为本地镜像，tagname 为标签名称，new-repo 为新的产户，tagname 为标签名，然后进行登录 docker hub，再将镜像推送上来。1、设置镜像标签在本地镜像中可以给镜像设置一个标签，下面先进行查看本地镜像，如：[root@localhost rw-test]# docker imagesREPOSITORY TAG IMAGE ID CRATED SIZErw_nginx latest cbd149510b76 8 minutes ago 440MBmytomcat latest 505be517d555 4 seconds ago 797MBcentos latest 67fa590cfc1c 4 weeks ago 202MB可以看到本地一共有三个镜像，而且镜像内存大小都比较大，所以这里示例就不推送本机的镜像了，那么接下来下载一个hello-world镜像，如：[root@localhost rw-test]# docker pull hello-world拉取成功后进行查看镜像，如：[root@localhost rw-test]# docker images…hello-world latest fce289e99eb9 8 mo… 1.84KB可以看到镜像大小只有1.84KB，所以等到推送时会比较快。然后继续对镜像设置一个标签，如：[root@localhost rw-test]# docker tag hello-world:latest 108001509033/test -hello-world:v2语句 docker tag 表示为设置镜像标签，对本地的 hello-world 中叫做 latest 的镜像进行设置标签，这里需要注意后面跟上的是自己的仓库名，这里示例为登录账号的仓库名，将镜像改名为test -hello-world，为了防止与以前的仓库冲突，这里版本号为v2，然后进行回车执行一次。此时再次进行查看，发现test-hello-world的标签为v2，大小还是为1.84KB，如：[root@localhost rw-test]# docker images…108001509033/test -hello-world v2 fce289e99eb9 8 …1.84KB紧接着将镜像进行推送，如：[root@localhost rw-test]# docker push 108001509033/test -hello-world:v2…errors :denied: requested access to the resource is deniedunauthorized: authentication required此时回车推送后出现报错，意思为无效认证，也就是如果要推送到 docker hub 中去，是需要登录的。2、登录 docker hub通过 docker login 进行登录，然后输入账号密码，如：[root@localhost rw-test]# docker login…Username: 108001509033Password :…Login succeeded执行结果如上则登录成功。3、推送镜像登录后再次执行推送，如：[root@localhost rw-test]# docker push 108001509033/test -hello-world:v2The push refers to repository [docker. io/108001509033/test-hello-world]…如上则推送执行成功。而到底推送成功没有可以通过刷新网页进行查看，刷新后查看页面如下： 可以看到页面中出现推送的v2版本，所以在这个里面成功的将镜像推送到 docker hub 中，而后期其他服务器需要镜像的话也是可以直接下载的。以上就是 docker hub 镜像仓库的使用。
2022年11月
-
11.25 12:38:27
发表了文章
2022-11-25 12:38:27
钉钉宜搭全命题解析 | 学习笔记
快速学习钉钉宜搭全命题解析
-
11.25 12:34:34发表了文章
2022-11-25 12:34:34
容器服务 AHPA 弹性预测最佳实践-元毅 | 学习笔记
快速学习容器服务 AHPA 弹性预测最佳实践-元毅
-
11.25 12:10:11发表了文章
2022-11-25 12:10:11
26PostgreSQL 对象安全控制 | 学习笔记
快速学习26PostgreSQL 对象安全控制
-
11.25 12:06:28发表了文章
2022-11-25 12:06:28
25 PostgreSQL 数据库安全认证 | 学习笔记
快速学习25 PostgreSQL 数据库安全认证
-
11.25 12:00:25发表了文章
2022-11-25 12:00:25
24PostgreSQL 日常维护和巡检 | 学习笔记（二）
快速学习24PostgreSQL 日常维护和巡检
-
11.25 11:56:15发表了文章
2022-11-25 11:56:15
24PostgreSQL 日常维护和巡检 | 学习笔记（一）
快速学习24PostgreSQL 日常维护和巡检
-
11.24 23:45:51发表了文章
2022-11-24 23:45:51
如何在 PolarDB - X 中进行 Online DDL｜学习笔记（一）
快速学习如何在 PolarDB - X 中进行 Online DDL
-
11.24 23:41:16发表了文章
2022-11-24 23:41:16
如何在 PolarDB - X 中进行 Online DDL｜学习笔记（二）
快速学习如何在 PolarDB - X 中进行 Online DDL
-
11.24 23:39:05发表了文章
2022-11-24 23:39:05
如何在 PolarDB - X 中进行 Online DDL｜学习笔记（三）
快速学习如何在 PolarDB - X 中进行 Online DDL
-
11.24 23:30:19发表了文章
2022-11-24 23:30:19
[视频]云原生数据仓库 AnalyticDB PostgreSQL 版解析与实践(上)｜学习笔记（四）
快速学习[视频]云原生数据仓库 AnalyticDB PostgreSQL 版解析与实践(上)
-
11.24 23:30:15发表了文章
2022-11-24 23:30:15
[视频]云原生数据仓库 AnalyticDB PostgreSQL 版解析与实践(上)｜学习笔记（三）
快速学习[视频]云原生数据仓库 AnalyticDB PostgreSQL 版解析与实践(上)
-
11.24 23:30:11发表了文章
2022-11-24 23:30:11
[视频]云原生数据仓库 AnalyticDB PostgreSQL 版解析与实践(上)｜学习笔记（一）
快速学习[视频]云原生数据仓库 AnalyticDB PostgreSQL 版解析与实践(上)
-
11.24 23:30:07发表了文章
2022-11-24 23:30:07
[视频]云原生数据仓库 AnalyticDB PostgreSQL 版解析与实践(上)｜学习笔记（二）
快速学习[视频]云原生数据仓库 AnalyticDB PostgreSQL 版解析与实践(上)
-
11.24 23:07:54发表了文章
2022-11-24 23:07:54
云上数据仓库的架构方案｜学习笔记（三）
快速学习云上数据仓库的架构方案
-
11.24 23:07:49发表了文章
2022-11-24 23:07:49
云上数据仓库的架构方案｜学习笔记（二）
快速学习云上数据仓库的架构方案
-
11.24 23:07:44发表了文章
2022-11-24 23:07:44
云上数据仓库的架构方案｜学习笔记（一）
快速学习云上数据仓库的架构方案
-
11.24 23:04:35发表了文章
2022-11-24 23:04:35
微服务用户为什么要选择云原生网关?｜学习笔记（二）
快速学习微服务用户为什么要选择云原生网关?
-
11.24 23:02:55发表了文章
2022-11-24 23:02:55
用 PolarDB - X + Flink 搭建实时数据大屏｜学习笔记（三）
快速学习用 PolarDB - X + Flink 搭建实时数据大屏
-
11.24 23:01:56发表了文章
2022-11-24 23:01:56
微服务用户为什么要选择云原生网关?｜学习笔记（一）
快速学习微服务用户为什么要选择云原生网关?
-
11.24 23:01:09发表了文章
2022-11-24 23:01:09
用 PolarDB - X + Flink 搭建实时数据大屏｜学习笔记（二）
快速学习用 PolarDB - X + Flink 搭建实时数据大屏
-
11.24 22:58:31发表了文章
2022-11-24 22:58:31
用 PolarDB - X + Flink 搭建实时数据大屏｜学习笔记（一）
快速学习用 PolarDB - X + Flink 搭建实时数据大屏
-
11.24 22:53:41发表了文章
2022-11-24 22:53:41
【视频】云原生数据仓库 AnalyticDB PG 解析与实践（下）｜学习笔记（四）
快速学习【视频】云原生数据仓库 AnalyticDB PG 解析与实践（下）
-
11.24 22:52:03发表了文章
2022-11-24 22:52:03
斯凯奇全渠道业务中台最佳实践｜学习笔记（二）
快速学习斯凯奇全渠道业务中台最佳实践
-
11.24 22:51:36发表了文章
2022-11-24 22:51:36
【视频】云原生数据仓库 AnalyticDB PG 解析与实践（下）｜学习笔记（三）
快速学习【视频】云原生数据仓库 AnalyticDB PG 解析与实践（下）
-
11.24 22:48:06发表了文章
2022-11-24 22:48:06
【视频】云原生数据仓库 AnalyticDB PG 解析与实践（下）｜学习笔记（二）
快速学习【视频】云原生数据仓库 AnalyticDB PG 解析与实践（下）
-
11.24 22:47:57发表了文章
2022-11-24 22:47:57
斯凯奇全渠道业务中台最佳实践｜学习笔记（一）
快速学习斯凯奇全渠道业务中台最佳实践
-
11.24 22:45:29发表了文章
2022-11-24 22:45:29
【视频】云原生数据仓库 AnalyticDB PG 解析与实践（下）｜学习笔记（一）
快速学习【视频】云原生数据仓库 AnalyticDB PG 解析与实践（下）
-
11.24 22:42:57发表了文章
2022-11-24 22:42:57
来电科技微服务治理落地实践｜学习笔记（二）
快速学习来电科技微服务治理落地实践
-
11.24 22:40:47发表了文章
2022-11-24 22:40:47
Dubbo 3.0 服务治理最佳实践｜学习笔记（二）
快速学习 Dubbo 3.0 服务治理最佳实践
-
11.24 22:39:45发表了文章
2022-11-24 22:39:45
来电科技微服务治理落地实践｜学习笔记（一）
快速学习来电科技微服务治理落地实践
-
11.24 22:37:20发表了文章
2022-11-24 22:37:20
Dubbo 3.0 服务治理最佳实践｜学习笔记（一）
快速学习 Dubbo 3.0 服务治理最佳实践
-
11.24 22:34:15发表了文章
2022-11-24 22:34:15
KubeVela 对接 Istio 实现应用灰度发布实践｜学习笔记（二）
快速学习 KubeVela 对接 Istio 实现应用灰度发布实践
-
11.24 22:27:50发表了文章
2022-11-24 22:27:50
【视频】云原生数据仓库 Analyticdb MYSQL 版-解析与实践-3｜学习笔记（四）
快速学习【视频】云原生数据仓库 Analyticdb MYSQL 版-解析与实践-3
-
11.24 22:27:02发表了文章
2022-11-24 22:27:02
KubeVela 对接 Istio 实现应用灰度发布实践｜学习笔记（一）
快速学习 KubeVela 对接 Istio 实现应用灰度发布实践
-
11.24 22:25:54发表了文章
2022-11-24 22:25:54
【视频】云原生数据仓库 Analyticdb MYSQL 版-解析与实践-3｜学习笔记（三）
快速学习【视频】云原生数据仓库 Analyticdb MYSQL 版-解析与实践-3
-
11.24 22:23:32发表了文章
2022-11-24 22:23:32
【视频】云原生数据仓库 Analyticdb MYSQL 版-解析与实践-3｜学习笔记（二）
快速学习【视频】云原生数据仓库 Analyticdb MYSQL 版-解析与实践-3
-
11.24 22:19:41发表了文章
2022-11-24 22:19:41
【视频】云原生数据仓库 Analyticdb MYSQL 版-解析与实践-3｜学习笔记（一）
快速学习【视频】云原生数据仓库 Analyticdb MYSQL 版-解析与实践-3
-
11.24 22:18:40发表了文章
2022-11-24 22:18:40
微服务治理实践之金丝雀发布｜学习笔记（三）
快速学习微服务治理实践之金丝雀发布
-
11.24 22:15:06发表了文章
2022-11-24 22:15:06
MSE 微服务测试---自动化回归最佳实践｜学习笔记
快速学习 MSE 微服务测试---自动化回归最佳实践
-
11.24 22:13:47发表了文章
2022-11-24 22:13:47
微服务治理实践之金丝雀发布｜学习笔记（二）
快速学习微服务治理实践之金丝雀发布
-
11.24 22:10:21发表了文章
2022-11-24 22:10:21
微服务治理实践之金丝雀发布｜学习笔记（一）
快速学习微服务治理实践之金丝雀发布
-
11.24 22:10:16发表了文章
2022-11-24 22:10:16
【视频】云原生数据仓库 AnalyticDB MySQL 版 _解析与实践1｜学习笔记（三）
快速学习【视频】云原生数据仓库 AnalyticDB MySQL 版 _解析与实践1
-
11.24 22:07:47发表了文章
2022-11-24 22:07:47
【视频】云原生数据仓库 AnalyticDB MySQL 版 _解析与实践1｜学习笔记（二）
快速学习【视频】云原生数据仓库 AnalyticDB MySQL 版 _解析与实践1
-
11.24 22:05:12发表了文章
2022-11-24 22:05:12
MSE 开发环境隔离功能介绍｜学习笔记（二）
快速学习 MSE 开发环境隔离功能介绍
-
11.24 22:04:30发表了文章
2022-11-24 22:04:30
如何开通实时计算 Flink 版｜学习笔记（三）
快速学习如何开通实时计算 Flink 版
-
11.24 22:03:16发表了文章
2022-11-24 22:03:16
【视频】云原生数据仓库 AnalyticDB MySQL 版 _解析与实践1｜学习笔记（一）
快速学习【视频】云原生数据仓库 AnalyticDB MySQL 版 _解析与实践1
-
11.24 22:00:11发表了文章
2022-11-24 22:00:11
如何开通实时计算 Flink 版｜学习笔记（二）
快速学习如何开通实时计算 Flink 版
-
11.24 21:59:52发表了文章
2022-11-24 21:59:52
MSE 开发环境隔离功能介绍｜学习笔记（一）
快速学习 MSE 开发环境隔离功能介绍
-
11.24 21:59:52发表了文章
2022-11-24 21:59:52
【视频】云原生数据仓库 AnalyticDB MySQL 版 _解析与实践1｜学习笔记（四）
快速学习【视频】云原生数据仓库 AnalyticDB MySQL 版 _解析与实践1
-
11.24 21:56:45发表了文章
2022-11-24 21:56:45
如何开通实时计算 Flink 版｜学习笔记（一）
快速学习如何开通实时计算 Flink 版
-
发表了文章
2022-11-25
钉钉宜搭全命题解析 | 学习笔记
-
发表了文章
2022-11-25
容器服务 AHPA 弹性预测最佳实践-元毅 | 学习笔记
-
发表了文章
2022-11-25
26PostgreSQL 对象安全控制 | 学习笔记
-
发表了文章
2022-11-25
25 PostgreSQL 数据库安全认证 | 学习笔记
-
发表了文章
2022-11-25
24PostgreSQL 日常维护和巡检 | 学习笔记（二）
-
发表了文章
2022-11-25
24PostgreSQL 日常维护和巡检 | 学习笔记（一）
-
发表了文章
2022-11-24
如何在 PolarDB - X 中进行 Online DDL｜学习笔记（一）
-
发表了文章
2022-11-24
如何在 PolarDB - X 中进行 Online DDL｜学习笔记（二）
-
发表了文章
2022-11-24
如何在 PolarDB - X 中进行 Online DDL｜学习笔记（三）
-
发表了文章
2022-11-24
[视频]云原生数据仓库 AnalyticDB PostgreSQL 版解析与实践(上)｜学习笔记（四）
-
发表了文章
2022-11-24
[视频]云原生数据仓库 AnalyticDB PostgreSQL 版解析与实践(上)｜学习笔记（三）
-
发表了文章
2022-11-24
[视频]云原生数据仓库 AnalyticDB PostgreSQL 版解析与实践(上)｜学习笔记（一）
-
发表了文章
2022-11-24
[视频]云原生数据仓库 AnalyticDB PostgreSQL 版解析与实践(上)｜学习笔记（二）
-
发表了文章
2022-11-24
云上数据仓库的架构方案｜学习笔记（三）
-
发表了文章
2022-11-24
云上数据仓库的架构方案｜学习笔记（二）
-
发表了文章
2022-11-24
云上数据仓库的架构方案｜学习笔记（一）
-
发表了文章
2022-11-24
微服务用户为什么要选择云原生网关?｜学习笔记（二）
-
发表了文章
2022-11-24
用 PolarDB - X + Flink 搭建实时数据大屏｜学习笔记（三）
-
发表了文章
2022-11-24
微服务用户为什么要选择云原生网关?｜学习笔记（一）
-
发表了文章
2022-11-24
用 PolarDB - X + Flink 搭建实时数据大屏｜学习笔记（二）
滑动查看更多
暂无更多信息
暂无更多信息