【架构】应用架构发展历史

短命女 2023-01-07 13:25 195阅读 0赞

任何一个网站在发布初期几乎都不可能立马就拥有庞大的用户流量和海量数据，都是在不停的试错过程中一步一步演变其自身架构，满足其自身业务。比如现在能够抗住双十一这么大流量的淘宝，它的技术最早用的是LAMP（Linux+Apache+Mysql+Php）。

随着互联网的发展，网站应用的规模不断扩大，常规的垂直应用架构已无法应对，分布式服务架构以及流动计算架构势在必行，急需一个治理系统确保架构有条不紊的演进。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw_size_16_color_FFFFFF_t_70_pic_center]

![在这里插入图片描述][2021011802484035.png_pic_center]

### 1.单体架构 ###

实际上，架构越复杂，意味着业务的体量越庞大。 对于一个刚刚起步的项目，我们会选择最简单最快速的方式来实现。而单体架构是最好的选择，目前很多的传统软件行业仍然采用这类的架构。 一般的实施方案是，把所有的功能模块都打包在一个（jar、war），并且部署在一个web容器 下，比如tomcat、weblogic、jboss中运行

![在这里插入图片描述][20210118024911919.png_pic_center]

**集群部署方式**

一旦用户量以及流量开始增加，服务器的性能就会遇到瓶颈，这个时候必须要对系统架构做调整以及优化。而在这个阶段主要需要解决的问题是提升业务系统的并行处理能力，降低单机系统负载，以便支撑更多的用户访问操作。

集群就是一种很好的方式，它可以把多台独立的服务器通过网络连接进行组合，对外形成一个整体提供服务。当一台服务器的处理能力接近或已超出其容量上限时，我们不会去尝试换一个更高性能的服务器，因为投入产出比不高，一般的做法就是采用集群技术，通过增加新的服务器来分散并发访问流量，只要业务系统能够随意支持服务器的横向扩容，那么从理论上来说就应该无惧任何挑战，从而实现可伸缩性和高可用性架构。

### 2.垂直架构 ###

虽然通过集群可以提升并行处理能力以及对于高可用的实现，但是同时还需要考虑到业务的复杂度，如果仍然把所有的业务逻辑全部耦合在一起放在一个war包中来管理，那对于代码的维护和扩展来说是非常困难的。而且如果某个业务功能出现故障，会导致整个系统不可用。

所以这个阶段要做的就是降低业务的耦合度，提升系统的容错性。 因此，这个时候可以对业务进行垂直化拆分，简单来说，就是可以按照系统的业务功能拆分出多个业务模块，比如电上网站，会拆分出：首页、用户、搜索、订单、支付、商品等子系统。 每个子系统由不同的业务团队负责。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw_size_16_color_FFFFFF_t_70_pic_center 1]

### 3.分布式架构 ###

随着对业务系统进行垂直化改造之后，以业务功能纬度拆分出来多个子系统，而在各个子系统中，会存在比较多的共享业务，比如用户信息查询，在支付业务中会涉及到、在首页中也 会涉及到。那么势必会造成重复开发产生非常多的冗余代码。那么这个时候就引入了服务化改造的思想，也就是SOA。

> SOA（面向服务架构），从语义上说，它与面向过程、面向对象、面向组件一样，是一种软件组建及开发的方式。所以在SOA中，服务是最核心的抽象手段，业务被划分为一些列粗粒度的业务服务和业务流程

把一些通用的、会被多个上层服务调用的模块独立拆分出来，形成一些共享的基础服务。这些被拆分出来的共享服务相对来说是比较独立，并且可重用。 比如用户管理服务，包含用户注册、用户查询等功能。比如单点登录服务;

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw_size_16_color_FFFFFF_t_70_pic_center 2]  
SOA 的核心目标就是通过服务的流程化来实现业务的灵活性，而这个流程化其实就是一系列相关联的任务组成，这一系列相关联的任务可以通过一系列的服务组合来实现具体的业务功能。

**分布式与集群**

分布式是一种应用架构，集群是一种应用部署方式，分布式服务的每一个节点都可以部署成单机或者集群。但在实际开发中，为了避免某个服务节点宕机后，导致所有依赖它的服务都不能正常运行，最终使整个分布式系统不可用，一般都会将服务部署成集群模式。

简单说，分布式是以缩短单个任务的执行时间来提升效率的，而集群则是通过提高单位时间内执行的任务数来提升效率。

### 4.微服务架构 ###

业务系统实施服务化改造后，原本共享的业务被拆分，形成可复用的服务，可以在最大程度上避免共享业务的重复建设、资源连接瓶颈等问题出现。那么那些被拆分出来的服务，是否也需要以业务功能为维度来进行拆分，使之能够独立进行部署，以降低业务藕合和提升容错性呢？

微服务并不是一种新思想的方法。它更像是一种思想的精炼，是一种服务化思想的最佳实践方向而已，所以可以认为微服务其实是在SOA思路下，随着各个企业对于服务化治理上不断的完善，以及对软件的交付链路以及基础设施逐步成熟之下的一种自然的产物。

微服务也是一种面向服务的架构模型，只是它更强调服务的粒度。也就是服务的职责更加单一更加精炼我们也可以把SOA看成是微服务的超集。 也就是多个微服务可以组成一个SOA服务。

> 微服务和 SOA 架构的区别？
> 
> 1.  SOA 关注的是服务的**可重用性**、以及解决企业内部的信息孤岛问题；微服务关注的是**解耦**，解耦和可重用性在特定的角度来看是一样，但本质上是不同的。解耦是降低业务之间的耦合度（也就是微服务关注的服务粒度），而可重用性关注的是服务的复用
> 2.  微服务会使用更轻量级的通信协议，使用Restful风格的API。轻量级协议可以很好的支持跨语言，是的语言生态更加丰富
> 3.  微服务会更多的关注Devops的持续交付，因为服务粒度更细使得开发运维变得更加重要。 所以微服务对于容器化技术的结合更加紧密
> 4.  SOA应该是微服务的超集

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw_size_16_color_FFFFFF_t_70_pic_center]: /images/20221119/5213483eb10d4ffdbeaed0a2f3e973a8.png
[2021011802484035.png_pic_center]: https://img-blog.csdnimg.cn/2021011802484035.png#pic_center
[20210118024911919.png_pic_center]: https://img-blog.csdnimg.cn/20210118024911919.png#pic_center
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw_size_16_color_FFFFFF_t_70_pic_center 1]: https://img-blog.csdnimg.cn/20210118024919958.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw==,size_16,color_FFFFFF,t_70#pic_center
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw_size_16_color_FFFFFF_t_70_pic_center 2]: https://img-blog.csdnimg.cn/20210118024929123.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw==,size_16,color_FFFFFF,t_70#pic_center