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

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

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、技术服务团队的服务态度也很重要。本来客户出了问题已经很着急，如果技术服务团队的态度散漫、态度不和蔼，甚至欺骗客户、拖延时间、内部协调不了，那客户就爆了。