(精华)2020年10月10日高并发高可用信息自动化

最新推荐文章于 2024-08-17 20:00:00 发布

愚公搬代码

最新推荐文章于 2024-08-17 20:00:00 发布

阅读量10w+

点赞数 1

分类专栏：高并发高可用

本文链接：https://blog.csdn.net/aa2528877987/article/details/108997860

版权

高并发高可用专栏收录该内容

21 篇文章 12 订阅

订阅专栏

高可用/并发架构带来部署和运维挑战

更多的服务器，更复杂的软件架构，更多的工作节点…… 更多的发布,部署，测试和运维挑战。

问题：高可用和架构安全的关系
在这里插入图片描述

持续发布/部署需求

持续部署和持续发布[CI/CD]：
复杂软件架构，往往带来更多的地面分层，更多的软件节点。系统的节点发布就会变得很麻烦。特别微服务系统得持续发布，持续部署就是为了解决这些问题

持续集成：
强调开发人员提交了新代码之后，立刻进行构建、（单元）测试,根据测试结果，我们可以确定新代码和原有代码能否正确地集成在一起

持续交付：
是在持续集成的基础上，将集成后的代码部署到更贴近真实运行环境(类生产环境)中。比如，我们完成单元测试后，可以把代码部署到连接数据库的Staging环境中更多的测试在这里插入图片描述

持续集成

持续集成(Continuous Integration, 持续集成)
持续集成是一种软件开发实践，即团队开发成员经常集成他们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试）来验证，从而尽早地发现集成错误。

常用的工具：Hudson和Jenkins 在这里插入图片描述

持续部署

持续部署(Continuous Delivery，持续交付)
在持续集成的基础上，将集成后的代码部署到更贴近真实运行环境(类生产环境)中。比如，我们完成单元测试后，可以把代码部署到连接数据库的Staging环境中更多的测试。如果代码没有问题，可以继续手动部署到生产环境。

Jenkins实现CD： https://blog.csdn.net/xiangnan10/article/details/80332866?utm_medium=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-1.nonecase&depth_1-utm_source=distribute.pc_relevant.none-task-blog-BlogCommendFromMachineLearnPai2-1.nonecase 在这里插入图片描述

自动化测试需求

自动化测试需求
复杂得软件架构，如：PAAS，SAAS，IAAS。过多得分层带来自动化部署，往往也带来自动化测试的需求。对于自动化，用代码来代替手工，软件测试就是在预设条件下运行系统或应用程序，评估运行结果，预先条件应包括正常条件和异常条件。 Selenium 架构图在这里插入图片描述

自动化运维需求

解决中小形的架构问题： 1.开发人员兼职完成，监控不及时 2.各式各样的脚本，重复性高 3. 人工参与度高，琐碎易犯错

ansible 自动化批量管理工具
jumpserver 堡垒机，用于开发人员使用服务器资源的权限
zabbix 监控工具，负责收集信息，实现监控，报警
notify 邮件、软件报警的方式
Jenkins +Git 系统的持续集成，项目的回滚操作
ELK 数据采集，统计分析

enkins

基于Java开发的一种持续集成工具，用于监控持续重复的工作，旨在提供一个开放易用的软件平台，使软件的持续集成变成可能

1、持续的软件版本发布/测试项目。

2、监控外部调用执行的工作。在这里插入图片描述

自动化发布架构图

https://www.jianshu.com/p/5f671aca2b5a

在这里插入图片描述

自动化发布—Msbuild配置

MSBuild 构建应用程序的平台。您可能不知道它，但是如果您在使用VS做开发，那么一定时时刻刻在使用它。因为是它在背后为你管理生成你的项目文件。当新建一个项目时，注意下项目文件夹中的*.*proj文件就是为MSBuild提供的，这是个文本文件，基于XML格式，里面包含有项目所包含的文件，生成配置，输出配置等信息。

学习网站：https://www.cnblogs.com/linianhui/archive/2012/08/30/2662648.html

Name:选择全局MSBuild配置的名称

MSBuild Build File:填写我们的要构建的项目.csproj文件，所相对工作的路径。如:/Test.csproj Command Line Arguments:MSBuild的参数如：/t:Rebuild /P:Configuration=Release /p:VisualStudioVersion=14.0 /p:DeployOnBuild=True;PublishProfile=Test.pubxml 在这里插入图片描述
持续部署
Jenkins攻略： https://www.cnblogs.com/heyuquan/p/jenkins-multi-env-cicd-architecture.html

CICD架构梳理

关键字：Jenkins,MSBuild,PowerShell 在这里插入图片描述

全链路自动化运维体系

在这里插入图片描述

扩展—DevOps平台

闭环：计划 --> 编码 --> 构建 --> 测试 --> 版本 --> 部署 --> 运维 --> 监控

四大模块在这里插入图片描述

持续交付环

在这里插入图片描述

架构安全—监控预警

云监控：https://help.aliyun.com/document_detail/35171.html?spm=a2c4g.11186623.6.557.2ebe5966nVqiph 在这里插入图片描述

架构安全的坑—过度设计

小公司里的大公司病
小公司里的大公司病在互联网洪潮的冲刷下，巨头IT公司积累的经验是普通公司不可比拟的，随之而来的是，互联网公司都喜欢遍地招这些巨头的员工，因为他们希望借助这些科技人才帮助公司茁壮成长，并且也能更好的进行融资和招揽人才。这些人才中，很大一部分是经过层层筛选出来的精英人才，他们掌握了良好的基础，拥有丰富的架构设计理论和实践。但是有一小部分是进去为了镀了一层金出来谋求更好的发展，或者靠实力进去后吃老本几年混不下去出来的人，他们精通各种话术（专业术语），信手拈来的成熟架构体系，大公司的资源丰富，于是养成了对服务器资源无节制使用，美其名曰背靠大山，不怕坐吃山空。常挂嘴边的口头禅：我们xx公司原来也是这么设计的… 在这里插入图片描述
反观上面的案例，都是不遵循架构的发展规律。架构是迭代设计出来的，没有通吃的标准架构，也没法一步到位，我们要因地制宜，层层递进，不断优化，最后才是适合自己的架构。尤其对于中小型公司来说，还没发展成型的项目始终存在着变动，我们应该设计应该是可扩展、易管理、易升级的架构，拥抱变化的同时不断优化，才不会因为笨重的包袱妨碍了奔跑的速度。