Java job interview:项目架构Java从开发、到测试、到发布、到运维

71 阅读 0 评论 47 点赞

我是靠谱客的博主沉静巨人，最近开发中收集的这篇文章主要介绍Java job interview:项目架构Java从开发、到测试、到发布、到运维，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

啤酒工业化流程属于工业时代的产物，经历了几十年的改造。而现在科技行业的互联网产品研发，只有将近20年。而且对于不同阶段的公司，由于技术的差异性，很难完全一样的去建立。每个公司随着从小到大的发展过程，必然要经历这样的技术体系建设过程。猎聘网也不例外。
之前的开发、测试、上线和运维流程：
互联网公司都会经历从小到大的阶段，技术人员规模也会经历不同阶段，从1人到10人属于初创期，10人到100人属于发展期，100人到1000人属于规模化发展期，从1000人到10000人甚至10万人属于大规模运行期。
猎聘网也经历了这样的发展过程，从1人发展到10人发展到100人，目前技术人员规模在几百人规模。正处于技术从手工到现代化的建设时期。
之前的一个产品开发会经历这样的阶段：
需求阶段：产品经理讲解需求，技术人员开发
开发联调阶段：所有技术人员共享1套测试环境，经常互相影响、互相依赖、查找问题耗时
测试阶段：十几个需求共享1套或多套测试环境，环境故障频发、不易解决，环境太多维护成本高，仅功能测试，安全、性能、API、回归等偶尔需要时靠手工，效率低；
发布阶段：排队上线，前期运维通过手工打包上传启动，后期通过脚本或工具启动，但需要用户服务停机、上线时间长；
生产阶段：早期线上服务宕机靠用户报告，后来服务靠监控宕机报警，而服务的质量、故障、响应速度、成功率等等都缺少完善的监控体系，对于服务治理和灾备降级等基本靠发现一例解决一例；
以上的状态，可以发现：研发人员缺少开发、测试的工具和环境，测试缺少一些自动化的工具，运维刀耕火种缺少持续发布检测的工具，服务监控问题发现和问题治理缺少工具。
随着需求上线次数达到每周几百上千规模、并行需求开发到几百个，这显然满足不了交付的速度和质量，而且问题频发。
下面就是早期开发人员和运维人员工作的环境：
随着人员规模增大、迭代速度加快、并行需求增多、服务规模扩大，我们来看看，一个产品应该怎样炼成的？
对于每周几千项目次上线、并行近百个需求开发测试、线上数千个服务实例的治理来说，传统软件的敏捷（如XP、Scrum、TDD）已不能适应这种灵活性。
互联网产品的特点，是需求多变、快速反馈、快速验证。这需要一套自动化的持续交付体系来保证开发、测试、上线、运维多个环节的频繁交付，来保证批量的小粒度需求被高质量开发、快速测试、快速部署到生产环境，并保证高质量运行和治理。
为了实现需求的持续快速交付，猎聘建设了一整套的持续交付体系，实现了软件开发、构建、测试、持续集成、部署和监控治理的全面自动化工具化。
下面是猎聘网所建设的整个持续交付体系：
网络分区如下：
开发环境区域，用户开发阶段测试
开发环境+公共区+存储区
发布环境+公共区+存储区
凤凰发布系统
持续集成区域，用于测试阶段的持续集成
Review+Sonar+Test+CI
线上发布区域，用户上线阶段的代码编译发布
发布+配置+编译+打包+指令
线上区，用于服务运行与服务监控治理
线上服务区：分多分区+存储区
线上服务中心：服务中心+作业调度+消息中间件
线上监控：日志+服务质量+调用链+监控
该体系分为4个大的阶段：
产品需求阶段：只需要建设响应的OA系统和流程就可以了；
开发阶段：能够快速、标准、持续的构建开发环境，让开发工程师能够互不影响的进行测试；
测试阶段：有一套多维度的持续集成系统，来检查潜在的代码问题；
发布阶段：从线下到线上、到配置、打包、编译、部署，一套工具体系来实现快速上线；
生产阶段：需要从硬件、服务、接口、代码、数据、流量等多维度监测和治理线上服务；
持续交付流程体系：
1、开发阶段–持续发布CP：快速构建测试环境、让RD/QA完成80%的功能测试。
包括：开发环境快速部署(凤凰系统)-＞测试环境快速部署(凤凰系统)-＞测试数据快速构建-＞OpenStack/KVM/Docker弹性发布等。
2、测试阶段–持续集成CI：自动化持续构建、帮助发现20%的代码潜在问题。
包括：代码自动评审(CodeReview)-＞代码静态检查(Sonar)-＞研发单元测试(UT)-＞QA自动化测试(UI-Selenium/APITest/APP)-＞技术可用性测试(性能/压力/安全)，并提供CI质量报告衡量代码质量。
3、发布阶段–持续部署CD：版本规划、打包、一键部署、多泳道发布。
包括：包编译服务(Compile)-＞版本包管理(Package)-＞CMDB配置(龙潭)-＞Env配置(闪电)-＞灰度(青龙)-＞生产线(青龙)，以及变色龙指令系统等；
4、生产阶段–持续监控CM：多维度监控、安全分析、调用链分析工具。
包括：硬件监控(Zabbix)-＞实时日志(雷达系统)-＞服务质量(红警系统)-＞调用链(CAT)
服务器标准化（主机+KVM+Docker未来）
部分主机：重要服务采用标准化主机，48G/96G+24core
部分KVM：OpenStack。部分不重要服务采用KVM共享资源
私有云：尝试Docker管理线下服务器，将IP、内存资源池化管理，减少CMDB运维成本，并逐步推行至线上。
猎聘目前的服务器采用主机+OpenStackKVM方式，正在考虑接入Docker进行资源池化的管理，来降低运维资源管理成本、便于扩容。