云计算时代的技术架构与开发模式

发表于:2017-2-23 10:14

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:阿朱说    来源:51Testing软件测试网采编

分享:
  DOS时代、Windows时代、Web时代、移动App时代,我们的开发语言、技术架构、调试方法、部署模式、运维模式,都发生着非常大的变化。那么我们来重新想象,云计算时代的技术架构和开发模式应该是什么样子?
  一、从一个普通程序说起
  我们常规写程序一般都是这样的构成:
  1、微软世界:ASP.NET、VB.NET/C#、SQLSERVER
  2、JAVA世界:JSP/Servlet、Struts/Spring/Mybatis、Oracle/MySQL
  3、PHP世界:类ThinkPHP这样的框架、MySQL
  往往我们在Web前端还要加点东西,如AngularJS、BootStrap,让前端代码显得更有结构,更多终端设备适配。
  要运行这些程序,我们通常在前端需要点Apache/Nginx,中间还需要点Tomcat/JBOSS/WebSphere/WebLogic之类的东西,底层还需要.NET运行环境/JAVA运行环境/PHP运行环境
  OK,可以部署了。
  过去不少云计算厂商搞AE(Application Engine)环境,期望开发商把应用软件一部署就OK。但是发现应用开发者在运行环境的组合方面挺多、版本要求也挺多,这事吃力不讨好,于是只提供纯粹的虚机环境了,对于各种组件组合和版本组合,由第三方的AE环境包研发商来提供了,大家可以在软件服务市场中购买到,而且很方便一键安装部署,对于没有什么特殊性能要求和分散部署要求的初创企业,一般就足够了。
  二、说说云计算IaaS产品线能提供的支撑
  作为云计算,我们先特指一下IaaS,大致是这些产品线:
  1、云主机:虚拟机、Docker容器。
  虚拟机大家都理解,打开了和一台裸机从感官上没差别。但是Docker需要应用Image镜像放到Docker容器中才能运行,这是很多人没有概念的。但是Docker容器更轻便,所以启动迅速、挂起迅速、占有资源少。不像虚拟机,还得安装操作系统和配置操作系统。
  当然,除了虚拟机和Docker容器,云计算厂商还提供物理服务器,供更高性能要求使用。
  2、云网络:CDN、SLB。
  CDN可以让静态文件缓冲,可以分发到全国,离用户访问的节点最近,这样访问速度最快。
  SLB是网络负载均衡,可以让你的应用从入口一进来就分流到各个主机上,分担了计算压力。
  云网络还有:VPN(虚拟专用网络)便于企业组内部广域网,高速传输通道可以用来传输大批量数据,专用网络用于高性能高安全的大客户使用
  3、云存储:文件存储、对象存储、块存储。
  这三者都能存各种文件(文档/图片/视频/音频),但是文件存储是可以建立文件目录结构的;对象存储是扁平的,它有KV索引,只需要关注某个文件放在哪个存储阵列里的那个磁盘上即可,你如果不需要建立文件目录结构,可以用对象存储;如果你对存储稳定性要求高,你可以用块存储,这就是咱们通常说的RAID存储,块存储会在底层保证数据的自动冗余复制多份,不需要应用者Care,所以某块物理磁盘出了问题,数据也不会丢失。你可以根据自己的需求来选择不同的云存储产品
  4、云数据库:关系型数据库、分布式关系型数据库、NoSQL。
  关系型数据库,常见的有:SQLSERVER、ORACLE、MySQL、PostgreSQL。
  现在还有一些关系数据库的中间件,可以做Sharding的自动分库分表,不需要应用开发者Care,如MyCAT。但这不是真正的分布式关系数据库。真正的分布式关系数据库,从底层架构设计时就是原生的分布式。
  分布式关系数据库,如Greenplum、TiDB(国人作品/京东老员工创业),阿里也出了一个Oceanbase。
  NoSQL,有KV型内存式的Redis、memcache,也有文档式的mongoDB。
  云数据库服务商会在后端提供可编排、自动化、自主化的数据库备份服务、迁移服务,让数据存取更稳定保障。
  可以这么说,IaaS给你提供了服务器、存储、网络、数据库,你可以把自己的程序放上去。
  三、说说可扩展的技术架构
  其实这个世界有很通用的可扩展技术架构方法,但中国中庸万金油的狗屎开发人太多,把所有子系统的代码都写在一起分不开,前后台代码都混在一起,代码和数据库混在一起分不开,导致想分散存取压力和计算压力都不能,只能不断加内存、升级CPU、升级网络带宽、升级存储设备性能。
  一般的可扩展技术架构方法是这样的:
  1、各个子系统模块代码分离,而且可以独立部署。
  2、需要开发一个企业门户,作为各个独立部署的子系统进行集成接入,也便于负载均衡分流路由
  3、各个子系统之间通过明确的统一规范的服务API接口进行连接,而且由SOA中间件在中间协调,而非交叉直连
  4、各个子系统要共同访问的数据,定义成主数据。有专门的数据库放置主数据,有专门的管理系统UI操作可以管理主数据,有专门的后台服务引擎来进行主数据的更新、日志、复制、分发推送,有专门的API服务用于其他程序通过接口来存取主数据
  5、统计报表和业务子系统分离,业务子系统的数据通过引擎复制导入到数据仓库,统计报表在数据仓库中做。这样统计报表可以满足更复杂需求、定制更灵活,而且运行时不影响业务子系统的正常处理。
  有这五条基本架构原则,好多企业应用就已经安顿住了。其他加加索引、优化一下SQL、归档一下历史数据,都是雕虫小技了。
  当然,你如果有更高的性能要求,云网络能帮助到你:SLB可以进行分流,你可以把一套子系统部署多套,部署到不同的服务器上,子系统代码运行,消耗最多的是CPU,而不怎么消耗内存、带宽、存储。当然,那你如果一个子系统部署多套的话,就出现了另外一个需求,你需要自动化的DevOps工具,来进行自动化的一次发布、多机多套部署,这样可以保证多台服务器上的代码逻辑是一致的。
  你还需要做动静分离。静态的,Apache/Ngnix、浏览器都会帮你做很多缓存,可以不用次次重新到服务器上取信息。而且云网络的CDN也可以帮到你,帮你把静态文件分发到全国各个节点,让用户就近访问。这样你就可以获得更高的性能了。
  如果你还需要更高的性能,云数据库可以帮助到你。不过你还得需要改你的代码架构。你需要应用Redis,把数据先打到内存中,程序会自动优先访问内存中的数据,而不用到磁盘中取数据。根据业务场景需要定时来更新内存中的数据。
  如果你还需要更高的性能,你还可使用分布式数据库。
  如果你还需要更更高的性能,你需要针对你的数据类型和特点选择不同的数据存储形式、不同的数据引擎了。所以各种各样的NOSQL就产生了,有的很善于处理时序型数据,有的很善于处理图状网状型数据,这样不管你是订单顺序,还是社交网络,都有合适的数据存储引擎,这样存取数据会更快。
  四、说说集成
  刚才提到可扩展的技术架构时没有提集成,因为咱们要专门提提。
  集成有这么几个层次:
  1、UI层:企业统一门户,单点登录
  2、UI层:URL调用。通过传入正确的Session和URL参数,以HTTP GET或POST方式进行访问,直接调用出其他子系统所属的UI窗口。当然这种调用是糟糕设计,而且各子系统独立部署还会产生XSS跨域访问问题。这样就把各子系统之间的调用都倒逼到逻辑服务层了。
  3、逻辑层:通过WebService、REST等方式暴露接口,进行接口调用
  4、逻辑层:很多烂程序,在逻辑层直接写很多SELECT、INSERT、UPDATE、DELETE的SQL语句,而且是跨各个子系统的。这是糟糕设计。所以一开始在代码开发的时候,就应该各个子系统是不同的代码库、不同的数据库,这样从一开始就不会产生跨子系统SQL调用
  5、数据层:有不少烂程序,N个子系统的数据表都放在一个数据库中,而且还写了不少VIEW、存储过程,甚至Trigger,这都是程序啊,程序都散在了各个层,而且都是跨子系统的,简直电线缠绕啊。所以我个人很倾向把各种代码都集中在逻辑层,把数据库就做成数据存取即可,不要给它赋予太多职责
  6、任务层:还有不少烂程序,有些后台需要根据条件触发或者定时调度执行的后台任务,这里面也写了大量代码。建议啊,逻辑代码也是放在逻辑层,而这个任务层代码只是进行调度组合即可,不要把详细的逻辑代码都写在这里。
  7、数据层:主数据集成。主数据如何被多个子系统更新、如何公开成服务被子系统调用、如何进行数据同步复制与分发
  8、数据层:统计分析集成。这需要做成独立的数据仓库来干
  可见集成,跨层纵向调用,水平横向之间调用,产生了多少交交叉叉,因而引发了多少牵一发动全身的事情。本来简单的事,就被万金油们搞成浆糊了。为了清晰的集成,我们有必要把调用都集中在逻辑层,而不是散在各处。
  为了清晰的集成,我们还有必要引入中间件。
  1、过去搞的是SOA中间件,解决接口之间的调用,不要让接口互相直接调用产生蜘蛛网,而是形成交通岗中枢进行中间指挥,在中间进行服务注册、发现、路由、安全验证、多协议传输。
  但互联网是网状的、分布式的、无中心的、不能单点失效的,所以SOA中间件的玩法就在云时代的互联网架构基础上玩不转了。要去中心化。
  近年火热的微服务架构和微服务中间件,和SOA有些不同。微服务架构讲究的是服务粒度更碎,服务能力更单一,形成Open API的形式,未来开发程序,都是基于在云上开放的Open API来直接组合,就形成了一个场景式的功能,AWS的lambda就是这个思路的尝试。在移动时代,不讲究上千个功能点的大集成的ERP套件,而更讲究一个APP满足一个核心场景,一个APP也就十来个功能。当然,你做的功能多了,移动屏幕就那么大,还是多点触摸式不好输入,移动APP就没法用了。
  至于Google的Protocol Buff和Facebook Thrift,只是为了让多语言之间进行顺畅的Service-client服务调用与数据传输,在小范围来看也属于服务中间件。
  2、有了单点登录、主数据Open API服务,那各个程序间的调用、数据、消息还是需要的啊。在云计算互联网时代应该怎么办呢?
  Kafka、Zookeeper上场。分布式的Kafka,通过消息队列管道,把数据、触发消息通知传送到Service-client两端。ZooKeeper来作为外协服务协调各个服务之间的调度。
  有了微服务架构、微服务中间件、Kafka、Zookeeper,过去集中式中枢式的SOA中间件就被瓦解了,被现在的分布式无中心式架构所代替,真正又回到了互联网的网状结构。
  五、总结一下云计算时代的技术架构模式和代码开发模式
  1、H5前端技术,适合各个设备
  2、微服务技术架构,一个功能点可能就是一个服务,对外公布Open API,供其他应用调用。微服务技术架构让代码不再混合,代码规模小,容易理解容易修改,新人容易上手
  3、微服务部署在Docker容器中,Docker隔离了各种基础支撑组件的部署相互影响的复杂性,这个微服务用到哪些支撑组件哪些版本就部署哪些,和其他微服务用的组件以及版本不打架,这让服务运维稳定性提高了许多
  4、云计算提供了专门的对象存储、块存储、CDN、SLB负载均衡、虚拟专用网络;云计算提供了各类云数据库,如MySQL、Redis、MongoDB、PostgreSQL等等;云计算提供了各类分布式中间件,如kafka消息队列、nutch爬虫、elasticsearch搜索;云计算厂商还提供了这些基础软件的运维,如备份、迁移、扩展、补丁升级等等。微服务只需要写好应用逻辑代码,其他需要的文件存取、数据存取、数据传输,都直接调用云计算提供的API就可以得到满足
  5、各种微服务都对外提供标准规范的Open API,这样的微服务越来越多,我们写一个应用,很多时候就是把各种Open API连在一起就可以构建成一个应用了
  6、我们的代码是托管在专有的云Github上,有专门的版本控制管理工具,有专门的研发工程效率工具,如自动化编译工具、自动化测试工具、多节点自动化统一部署工具、灰度发布工具、项目计划和任务管理工具、文档管理/需求管理/BUG管理工具,这些也都部署在基础的云IaaS中。
  六、最后谈谈云计算IaaS的选型
  对于创业小公司,一般这样选型云计算:
  1、域名便利:方便域名注册、域名绑定、域名备案
  2、支付便利:如支付宝、微信支付,扫码付款即可
  3、价格低廉:如一个月100多元,一年才1000多元
  4、有AE包:可以网上选择、网上付款,甚至0元促销,直接一键安装。很容易就把自己的程序部署上去
  5、提供基础应用:如免费的企业邮箱。如果有免费的wordpress和企业模板,不用安装,直接开通,直接域名绑定,企业的官网就有了。一个企业的架子就很快搭起来了,从外面看来很像一家正规公司了
  对于中公司选型云IaaS:
  1、各种引擎很重要。中公司,自己的应用做的很好,但是大部分研发力量主要都投入到应用研发上了,他们没有能力来研发以及运维大规模的基础引擎,所以如果云计算厂商能提供好多底层的引擎,他们就会直接使用。如搜索推荐引擎、人工智能引擎、大规模日志引擎、大数据技术平台。又不用自己研发,又有现成的高科技给自己主力,多好
  2、价格。又想吃好肉又想价格低,所以只能随业务增长量来收费,这样容易接受。但是因为所有业务应用都受基础引擎支撑,所以想迁走就基本不可能了,只能细水长流
  3、有比较保障的云安全:至少不能动不动就被DDoS攻击、被安装了肉鸡木马、被感染了病毒。中公司的研发人都主要偏向于应用研发,一般没有专门的安全技术力量。
  对于大公司选型云IaaS:
  1、稳定很重要。如网络稳定、存储稳定、内存CPU主板稳定、电力稳定。这是需要云计算厂商投大钱的,钱没投上,只选择低端货,那自然不稳定,性能也不高
  2、解决方案很重要。大公司一般应用复杂,要求异地多备份、多地多活、流量分流、快速切换,这需要云计算有很强大的技术解决方案能力。甚至有些大公司为海外提供服务,所以也非常看重云计算厂商在世界各地如香港、日本、东南亚、欧洲、美国的云计算资源能力
  3、技术支持很重要。出了问题,可以快速响应,快速查找到问题根源,快速修复或快速升级。这对云计算厂商的技术团队的规模、技术能力、自动化工具、跨部门之间的良好协作,要求很高。
  4、技术服务团队的服务态度也很重要。本来客户出了问题已经很着急,如果技术服务团队的态度散漫、态度不和蔼,甚至欺骗客户、拖延时间、内部协调不了,那客户就爆了。
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号