高可用/并发架构带来部署和运维挑战
更多的服务器，更复杂的软件架构，更多的工作节点….. 更多的发布,部署，测试和运维挑战。
问题：高可用和架构安全的关系
持续发布/部署需求
持续部署和持续发布[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公司原来也是这么设计的…
反观上面的案例，都是不遵循架构的发展规律。架构是迭代设计出来的，没有通吃的标准架构，也没法一步到位，我们要因地制宜，层层递进，不断优化，最后才是适合自己的架构。尤其对于中小型公司来说，还没发展成型的项目始终存在着变动，我们应该设计应该是可扩展、易管理、易升级的架构，拥抱变化的同时不断优化，才不会因为笨重的包袱妨碍了奔跑的速度。