传统IT的变革——从购买硬件到租用服务
纵观十年的软件行业发展,云计算,云服务已经逐渐深入到了互联网企业的日常运作当中。云服务的便捷性,可靠性,安全性,成为了企业降低综合成本、提高人员利用率的不二法宝。
2010年,项目组特意购买了十多台DELL的小型服务器以及一些硬件设备,用于电信软件产品的开发测试。为了确保这些宝贝疙瘩的稳定运行,我们特意重新装修了一个办公区域。除了强弱电这些基础改造外,我们还铺设防静电地板,安装独立空调,更换灭火喷淋设备,甚至还特意规划出了一个更衣区域。
2020年,借助于云服务,软件研发的办公地点变得格外灵活,不管是在公司,还是在家,甚至在动车上。
服务器上云
2014年底,我入职一家商业软件企业,该公司主要通过销售软件盈利。
公司的办公区域也有一个10平米左右的机房,里面除了陈列着好几个机柜外,空置区域还放置着好几台服务器,地面和天花板上可见各种临时接的网线。只要一打开门,各种服务器的轰鸣声就会覆盖整个办公区域。就算配备了UPS应急电源,也不排除一些极端情况导致服务器断电,出现官网无法访问的情况。并且,还得安排专人负责机房的温度、湿度、以及可能出现的墙壁渗水,服务器宕机等状况。
2016年开始,我们摒弃了把官方网站放在自有服务器上的方式,而是采用租赁阿里云ECS,把整个官网放到了云上。这样,就不需要考虑本地机房或者IDC机房是否会由于停电导致官网无法访问,也无需考虑关于机房的实际情况。
在这期间,还发生过一件有趣的事情。运维团队直到服务器续费时才发现由于扩容疏忽没有手动重启实例,导致了一年前的购买的扩容包实质上并没生效。也就是说,该ECS实例已经零停持续运行了一年以上的时间。
至于服务器的安全性,通过设置访问白名单,把阿里云的ECS服务器的远程管理端口仅仅开放给研发运维团队所在网络,运维团队通过VPN登录跳板机对服务器网站进行更新。除了有次因为Docker自身漏洞导致的异常登录报警外,服务器没有出现过其他的安全相关问题。
在前期,我们的数据库服务器依然是使用手动安装在ECS上的Mysql-Server,由公司运维人员进行日常维护的,偶尔会出现诸如磁盘空间耗尽所导致数据库错误的情况,运维团队会花费人力去分析解决由于环境所导致的各种问题。因此,我们开始思考一个问题,既然阿里云新出了云数据库,为什么不尝试尝试呢?借鉴灰度发布的经验,我们把测试环境的数据库切换到了云数据库,在运行一段时间后,云数据库的优势已经很明显了,维护方便,性能也够用。据此,生产环境的数据库也顺理成章的切换到了云上,通过数据库迁移的方式把原本存储在ECS上的内容切到了云数据库里。
逐渐,企业的测试环境和生产环境也全都上云了,不同环境之间通过VPC技术进行网络隔断。这下,企业机房里的设备仅仅剩下企业路由器和交换机。同时,我们还是保留了几台用于存储备份云上数据的服务器了。后来发生的“前沿数控技术事件”,证明了在本地做一定程度的备份还是很有必要的。为了进一步压缩机房空间,我们把有线网络做了进一步的精简,企业日常办公所使用的网络也从有线网络逐步切换至无线网络。并且在研发团队的无线网络出口增加了个跳板机,研发同事能够无障碍的链接到云上研发测试环境中。
应用上云
以往的研发经历中,我们有购买第三方商业插件授权,用于数据报表统计相关工作。但是因为缺乏持续维护更新,该插件属于。偶尔,开发和测试的同时会相视一笑:又是那个插件的问题,对吧。
新的架构设计中,我们放弃了购买第三方的商业插件的计划,而是把目光投向了云服务。
系统中工商证照的读写功能,分别涉及到了证照的存储和识别两个技术点。按以往的开发模式,证照图像的存储会首先由运维工程师规划相应的目录,后端研发工程师根据项目的实际需要,通过编码的方式对文件进行管理。在这其中不可避免会涉及到文件存储介质,用户访问权限,运维容灾等问题。而证照识别方面,相对简单的方法就是参考部分开源项目,通过GPU运算对模型进行进一步的调优,然后通过后续业务对模型进行持续深入的优化。
用云服务替代独立授权插件在可维护性上有着无可比拟的优势,相关模块在开发效率和质量上都会有很大的提升。文件存储模块仅仅需要研发工程师调用云服务的API就可以完成文件存储的相关功能。而证照识别不仅正确度更高,而是费用也会大幅度降低。详见《OCR-链接》。而由于云服务的本质,使得这个购买的行为不再是一锤子买卖,而是按量计费,如果服务存在任何问题,随时可以通过简单的接口调整切换至备选的方案。以存储为例,这块在国内的大型云服务提供商备选方案有亚马逊AWS的S3,阿里云的OSS,以及腾讯的COS。由于前沿数控技术数据丢失的事情《加腾讯云声明》,腾讯云的COS被首先给排除了。亚马逊S3,稳定性和可靠性是没问题的,价格相对较高。而阿里云的OSS,在价格上相比AWS来讲会便宜些。加上我们现有的云服务器均使用ECS,所以,阿里云的OSS成为了我们的第一选择,而AWS则成为后备。
服务上云
在服务器和云服务上云后,我们开始思考另一个问题,能否借助于云服务,进一步降低服务器的运维成本,提升整体效率。
阿里云的ECS上除了运行着开发环境和测试环境外,还有不少的研发环境也在ECS上。例如,用于代码版本控制的Gitlab,任务管理系统Redmine,持续集成工具Jenkins,测试用例管理TestLink等。这些应用通过私有化部署方式安装,运维工程师通过升级的方式修复当前版本的缺陷,或者导入新的功能。除了在升级前做模拟外,每次升级还需要选择非工作时间进行。升级过程一旦出现异常,就得投入更多的时间和人力用于版本回滚、数据恢复的问题,甚至会对正常的研发工作造成影响。
以版本控制工具为例,云上主要有两种形态的产品提供方式,独立SaaS服务商和云服务商两种。独立的SaaS提供商专注于代码版本管理,依托代码管理工具做相应的扩展,例如:Gitee、Gitlab、Github、Bitbucket等。云服务商则是更倾向于提供一体化的研发过程解决方案,例如阿里云效,华为DevCloud,腾讯云Coding DevOps。结合项目的实际情况和方式,我们选择相对保守的策略,使用Gitee作为云上的版本控制工具。除了部分核心代码外,所有的业务代码均存放在Gitee上,并通过中间服务器将每一次提交及时同步到备份服务器上。
当疫情爆发时,线上环境恰到好处的承载了虚拟团队的研发需求。业务开发模式快速从集中办公切换至WFH。针对虚拟团队运作过程中所发现的家用PC机性能和存储问题,后续考虑看看在线的IDE和文件存储NAS吧。