分布式架构的演进

前言

分布式架构是什么？是不是一切可以水平扩展的，或者为了解决水平扩展的架构，都可以认为是分布式架构？云计算时代分布式架构该如何适配？问这么多，开始正文啦！

架构的演进

业务之初，业务量小且不确定性大，搭建一个单体应用就可以了。这时候的架构是这样的

单体应用

上线之后，为保证不停机发布，引入nginx做反向代理，部署两个应用节点以解决应用单点问题，同时提高吞吐能力。

Nginx做反向代理及负载均衡

有了数据之后，考虑容灾问题，需要给数据备份，同时增加数据库读写能力，因此将数据库扩展为主从。

Mysql集群

数据达到一定的量之后，发现热点数据访问出现性能问题，于是引入缓存

分布式缓存

当某部分数据越来越多，且需要做复杂的关联查询、全文搜索等需求时，Mysql表现非常差，这时需要引入搜索引擎。

分布式搜索引擎集群

如果系统有大量的文件需要被客户端访问，文件存放在自己的服务器上面，必然会带来流量占用和带宽不足的问题，并且远距离传输用户体验也不好，这时需要引入CDN。

CDN网络

随着业务发展，业务越来越复杂，需求越来越多，团队成员也越来越多，这时单体应用会带来很多制约，业务、代码耦合度高、功能交织，牵一发而动全身，这给系统稳定性带来极大挑战；而且多个开发人员维护同一段代码，代码冲突将让新功能的开发变得特别困难。这时候急切需要将功能和代码进行拆分。

单应用拆成多个子应用

如果业务发展到需要同时开展多条产品线，而这些产品线是有共同的特点的，比如阿里巴巴的淘宝商城之后，要再搞一个天猫商城、聚划算、咸鱼、飞猪···它们的用户、商品、交易、支付等功能是一样的，只是业务模式不同，这时需要把共同的地方抽离出来，避免重复造轮子。于是应用再次拆分

中台架构

分布式RPC框架

应用拆分后，应用间的数据交互需要通过网络进行，因此要引入一款高性能的分布式远程服务调用框架，比如Dubbo、Spring Cloud，在这里需要用到很多我们耳熟能详的分布式技术，比如服务治理、负载均衡、高可用、流量治理、动态伸缩等。而我们的应用，或者中台如何将自己的功能提供给外部使用，这便引出另一种架构思想——面向服务架构和微服务。严格讲，微服务应该是面向服务架构的延伸，面向服务架构的概念包含了微服务的思想，这里我们就不展开讲啦。我们继续看分布式RPC框架，下图是Dubbo的架构图

服务提供者将服务注册到注册中心，消费者订阅需要的服务，剩下的所有分布式事项都交给Dubbo实现，比如上面提到的服务治理、负责均衡等等，都不需要用户关心。

分布式消息

应用拆分之后，甚至应用拆分前，都会有大量的异步操作需要处理，这是需要引入一款高性能的分布式消息中间件以解决异步操作的问题。业内成熟的产品也挺多，比如RocketMQ、ActiveMQ、RabbitMQ、Kafka，下面是RocketMQ的架构图

RocketMQ架构图

分布式数据库中间件

随着时间推移，数据库的数据必然越来越多，终会达到一张表或者一个库无法再存储的地步，因此要在这出现之前解决单库单表数据存储极限的问题。这就需要一款高性能的分布式数据库分库分表中间件来解决了，比如ShardingSphere、Cobar、Mycat，我个人会使用ShardingSphere，因为它更轻量，它依然是基于JDBC，只是对JDBC进行了修改。Cobar和Mycat则是放弃了JDBC，使用Mysql原生协议同数据库通讯，这样会比较重，对应用来说它就是数据库。使用分布式数据库中间件，就可以按照一定的规则将一张表拆成多张表存在同一个数据库或不同的数据库，可以将一个库拆成多个库，通过数据库中间件来完成路由请求、数据合并、重新排序等操作，对应用来说，而这一切应用是无感的。下图为Sharding-JDBC架构图

Sharding-JDBC架构图

架构演进到这里，一个较完整的，能支撑大规模并发且可以动态伸缩的分布式系统算是落地了。当然，这决不是分布式系统的全部，还会有很多的需求或者工作，比如分布式文件系统、分布式事务、分布式日志系统、监控系统、容器技术、运维等等。我们来看下经过上面的演变，现在的架构图是怎么样的，如下

基本成型分布式架构图

事情到这里就结束了？没有！！因为云时代已经扑面而来了。云计算时代分布式应用架构应该怎么做呢？

云端上的架构

云计算是啥？百度了一下，百度百科的解释是：云计算实质就是一个网络，狭义上讲云计算是一种提供资源的网络，使用者可以随时获取“云”上的资源，按需求量使用，并且可以看成是无限扩展的；从广义上说，云计算是与信息技术、软件、互联网相关的一种服务，这种计算资源共享池叫做“云”，云计算把许多计算资源集合起来，通过软件实现自动化管理，只需要很少的人参与，就能让资源被快速提供。嗯，有道理。

也就是说，云计算是提供资源的。目前交付资源的形式主要有三种，Iaas、Paas、Saas，现在又新提出了一种Baas。我们先来看看这概念指的是什么，它怎么影响应用架构的。

Iaas

Iaas是Infrastructure as a Service的缩写，就是基础设施即服务。这个容易理解，云计算就是在一个网络里提供资源的，把像服务器、存储、计算等基础设施提供出来，让外部按需获取这些资源。比如阿里云的ECS，腾讯云上面的CVM。

Paas

Paas是Platform as a Service的缩写，就是平台即服务。平台一般指服务平台、开发平台、运维平台等，将这个平台的所有能力作为服务对外提供。比如阿里云的EDAS，就是一个应用托管和微服务管理的Paas平台，它提供应用开发、部署、监控、运维等全栈式解决方案，并且提供微服务运行环境。应用开发者只需要关注自己的业务代码就好了，剩下交给云平台。但是，EDAS的每一项功能都是付费的，而且有的是按流量付费。

Saas

Saas是Software as a Service的缩写，就是软件即服务，也就是通过云提供软件服务。这种模式现在很多，有提供某条垂直线的一站式服务，比如电商领域的进销存，CRM等；有提供某个功能的服务，比如安全、人工智能系列等。

云计算如何影响应用分布式架构设计

其实我们在演变上文的分布式架构的中，就已经使用了部分云计算的资源。我们的服务器一般都直接采购云上的，毕竟云上的服务器更加廉价、方便，特别是扩缩容的时候，而且运维成本很低，安全系数高。CDN、缓存、数据库其实应该使用云上资源更靠谱，安全系数高，几乎不会出现数据丢失的情况。基础设施上云我是完全支持的。

很多中间件也被云化，云上的中间件优势也是特别明显的，人性化的控制台，一站式的提供服务、监控、告警、容灾、恢复等，特别重要的是低成本的弹性扩容。得益于软件领域的开源文化，现在很多中间件已经被开源，其实现在去获得一项中间件技术并不是特别困难，只要投入一定的研发力量去调研，就能获取。而且开源社区的力量非常强大，有的中间件特别有活力云计算框架图，完全能媲美商业版中间件。所以，我现在对中间件上云的意愿还不是很强烈。

云上的软件服务，如何来选择呢，我会选择使用某些特殊功能的云服务，比如安全等，毕竟云平台提供的服务更有保障。还有人工智能系列，自行开发的成本太高。一些垂直线的一站式服务，在创业的初期，其实使用它们会更加划算，很快你就能展开自己的业务，而且能用上这些厂商在这垂直线上的一些经验积累。但是业务发展起来之后，自研会更靠谱。马云的一句名言：唯一不变的是变化。每个公司的业务千变万化，且市场也在不断变化，云平台的服务怎么可能跟着你快速适应变化呢。

云计算的优势显而易见，节约资源、降低成本的同时提供强大的能力，所以架构云化一定是大势所趋。虽然现在开源世界还足够活跃，从开源世界获取资源的成本也不是特别高，但是现在云计算的目标是完全不需要成本就能获取资源和能力，开发人员不需要关注底层的技术，你只做好业务的代码就可以了。所以，云计算会慢慢吞噬开源，未来开源世界会怎么样我不知道，起码，越来越少人会再去关注底层的技术了吧。当有一天云计算的成本足够低且功能足够强大，比如EDAS，如果使用它的成本比自研或者从开源世界获取资源搭建同样的功能成本要低得多，而且业务量上去之后同样能维持在一个较低的水平，那谁还去关心开源呢。下面是一个自研或用商用的一个概念图，可能对大家在选型上有一些帮助

自研VS商用概念图——图片来自《淘宝技术这十年》

云计算是未来，云原生架构就是未来。我认为即便现在你的应用不上云，也应该做好一些云化的改造，或者我们可以叫它上私有云。云原生的概念就是为云而生，云原生应用就是指专门为在云上部署、运行而设计的应用。所以云原生应用应该具备可用性、可伸缩性、无状态，持续集成持续部署等特点，即应符合云原生12要素。云原生12要素我们这里就不展开啦，它的目标就是让应用能够在容器中部署，容器是与环境无关的、无状态的、可随时随地扩容或缩容的。应用能持续集成和持续部署才能更完美配合容器发布。

结束

云计算是未来，云原生架构是为云而生的，应用容器化和全部上云或者部分上云是大势所趋，应该尽早用云原生的设计模式去改造应用的架构。

（编辑：晋中站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!