信息自动化

Posted 2020-12-11 qingyunye

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

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

问题：高可用和架构安全的关系

持续发布/部署需求

持续部署和持续发布[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

自动化部署—Azure Pipelines

实现方式：https://blog.csdn.net/playermaker57/article/details/87901531

 

自动化部署—Gitlab-Ci 

Gitlab-Ci Runner：https://www.jianshu.com/p/705428ca1410 

 

自动化测试实现 

压测：jmeter+Maven/Ant+Jenkins+mysql+testlink/redmine     https://www.cnblogs.com/xixiuling/p/11197291.html

 

全链路自动化运维体系

 

扩展—DevOps平台

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

四大模块

 

 

持续交付环

 

架构安全—监控预警

云监控：https://help.aliyun.com/document_detail/35171.html?spm=a2c4g.11186623.6.557.2ebe5966nVqiph

 

架构安全的坑—过度设计

小公司里的大公司病

小公司里的大公司病在互联网洪潮的冲刷下，巨头IT公司积累的经验是普通公司不可比拟的，随之而来的是，互联网公司都喜欢遍地招这些巨头的员工，因为他们希望借助这些科技人才帮助公司茁壮成长，并且也能更好的进行融资和招揽人才。这些人才中，很大一部分是经过层层筛选出来的精英人才，他们掌握了良好的基础，拥有丰富的架构设计理论和实践。但是有一小部分是进去为了镀了一层金出来谋求更好的发展，或者靠实力进去后吃老本几年混不下去出来的人，他们精通各种话术（专业术语），信手拈来的成熟架构体系，大公司的资源丰富，于是养成了对服务器资源无节制使用，美其名曰背靠大山，不怕坐吃山空。常挂嘴边的口头禅：我们xx公司原来也是这么设计的…

 

反观上面的案例，都是不遵循架构的发展规律。架构是迭代设计出来的，没有通吃的标准架构，也没法一步到位，我们要因地制宜，层层递进，不断优化，最后才是适合自己的架构。尤其对于中小型公司来说，还没发展成型的项目始终存在着变动，我们应该设计应该是可扩展、易管理、易升级的架构，拥抱变化的同时不断优化，才不会因为笨重的包袱妨碍了奔跑的速度。