常见系统架构的介绍

      我们平时都会听到什么单体架构、微服务、分布式项目，那么这些都是啥意思呢？我们在开发前应该咋么选型（虽说我是个菜菜架构方面不用我考虑，就当是先学习学习），那么我们就得先了解一下有哪些常见的系统架构，有那些优缺点？

1、写在前面

      任何一个架构不会一上来就搭建微服务架构，而是一步一步跟用用户量、访问量来演变的，除非能确定我的业务需求非常的复杂，有很多用户访问量；因此，我们要明白在什么样的场景应该使用啥样的架构；

系统架构大致有以下几种：

• 单体应用架构
• 垂直架构
• 分布式架构
• SOA架构
• 微服务架构

2、单体架构

      单体架构就是将所有的功能代码部署在一块，可以减少开发、部署和维护的成本；他包含了应用所有功能的应用程序是一种比较传统的架构风格，只实现最简单，最基础的功能；

      换句话就是说将所有的业务场景的前台表示层、中间业务逻辑层和后台数据访问层都放在一个工程中，最终经过编译、打包，部署在一台服务器上，如下图：

      在一些小型应用的初期，访问量小的时候，这种架构的性价比还是比较高的，开发速度快，成本低，但是随着业务的发展，逻辑越来越复杂，代码量越来越大，代码的可读性和可维护性越来越低。用户的增加，访问量越来越多单体架构的应用并发能力十分有限。这种架构虽然有一定的并发能力，及应对一定复杂业务，但是依然没有改变系统为单体架构的事实。大量的业务必然会有大量的代码，代码得可读性和可维护性依然很差。如果面对海量的用户，它的并发能力依然不够。

优点：

• 项目架构简单，小型项目开发成本低；
• 项目部署在一块，维护方便；

缺点：

• 全部功能集成在一个工程中，对于大型项目来讲不易开发和维护
• 项目模块之间紧密耦合，单点容错率低
• 无法针对不同模块进行针对性优化和水平扩展

3、垂直架构

      随着访问量的逐渐增大，单一应用只就无法满足需求了；所谓的垂直应用架构，就是将原来的一个应用拆成互不相干的几个应用，以提升效率；

      比如电商平台，如果用户访问增加但是又并不是对所有的模块都会有比较大的访问量，可能对用户管理和订单管理的影响比较大对消息中心的影响就比较小，那么我们就希望只多增加几个订单模块， 而不增加消息模块，再比如CMS应用宕机了，其他的应用也不想被受影响；此时单体应用就做不到了， 垂直架构就应运而生了；

我们根据业务功能可以将上面电商的单体应用拆分成以下部分：

• 电商系统(用户管理 商品管理 订单管理)
• 后台系统(用户管理 订单管理 客户管理)
• CMS系统(广告管理 营销管理)

这样拆分完毕之后，一旦用户访问量变大，只需要增加电商系统的节点就可以了，而无需增加后台和CMS的节点。

优点：

• 系统拆分实现了流量分担，解决了并发问题
• 可以针对不同模块进行优化和水扩展
• 一个系统的问题不会影响到其他系统，提高容错率

缺点：

• 系统之间相互独立， 无法进行相互调用
• 系统之间相互独立， 会有重复的开发任务
• 搭建集群后，实现负载均衡比较复杂

4、分布式架构

      当垂直应用越来越多，重复的业务代码就会越来越多。这时候我们就得考虑将重复的代码抽取出来，由前端控制层调用不同的业务层服务，于是这就产生了新的分布式系统架构。

      分布式系统架构把工程拆分成表现层和服务层两个部分，服务层中包含业务逻辑。表现层只需要处理和页面的交互，业务逻辑都是调用服务层的服务来实现。

      如下图，变现层依然不变该点那里还是哪里，但是有公共的服务层可以相互调用；

优点：

• 抽取公共的功能为服务层，提高代码复用性

缺点：

• 系统间耦合度变高，调用关系错综复杂，难以维护

5、SOA架构

      在分布式架构下，当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个治理中心对集群进行实时管理。此时，便引入了SOA（Service Oriented Architecture）架构；

      在SOA系统中会有一个服务注册中心，我们将服务注册到服务注册中心中（必须要放在服务注册中心，中心化的强耦合），他就会一直监控着每一个服务，当某一个服务宕机时服务注册中心就会将其排除在外不会调用，直到该服务正常，这就解决了服务调用异常的问题；同时也会根据某个协议进行调整，将一个协议转为另一个协议，这就解决了各个应用间协议不同的情况；

优点：

• 使用治理中心（ESB\dubbo）解决了服务间调用关系的自动调节

缺点：

• 服务间会有依赖关系，一旦某个环节出错会影响较大( 服务雪崩 )
• 服务关系复杂，运维、测试部署困难

6、微服务架构

      微服务架构就是对之前的架构进行更彻底的细粒度拆分，在某种程度上是面向服务的架构SOA继续发展的下一步，它更加强调服务的”彻底拆分”。比如之前的一个商品模块可以拆分为普通商品模块、特价商品模块、秒抢商品模块等等，但是拆分的力度还是要根据业务的复杂度来进行拆分的；同时还引入了治理和协调的微服务组件以及各种组件去解决其它问题，比如服务器雪崩，去中心化啥的；

将每一个模块都拆分成一个个的服务；

优点：

• 服务原子化拆分，独立打包、部署和升级，保证每个微服务清晰的任务划分，利于扩展
• 微服务之间采用Restful等轻量级http协议相互调用

缺点：

• 分布式系统开发的技术成本高（容错、分布式事务等）
• 复杂性更高，各个微服务进行分布式独立部署，当进行模块调用的时候，将会变得更加麻烦。

7、微服务架构补充

7.1、微服务架构的常见问题

一旦采用微服务系统架构，就势必会遇到这样几个问题：

1. 这么多小服务，如何管理他们？(注册中心 nacos)
2. 这么多小服务，他们之间如何通讯？(restful rpc dubbo feign)
3. 这么多小服务，客户端怎么访问他们？(网关 gateway)
4. 这么多小服务，出现问题，应该如何自处理？(容错 sentinel)
5. 这么多小服务，出现问题，应该如何排错? (链路追踪 skywalking)

7.2、微服务架构框架图

      首先从客户端发送请求，通过负载均衡分发到达对应的网关，实现负载均衡主要是为了减轻网关的压力；然后网关通过nscos注册中心获取服务列表也就是拿到名称；之后通过熔断降级（防止发生雪崩之类的问题）找到对应的微服务，然后会采用Feign来进行服务间的调用；最后会使用一些OSS、MQ、Redis等等；

7.3、常见的微服务架构

微服务架构只是一种风格，那么我们可以有多种实现方式；

7.3.1、dubbo: zookeeper +dubbo + SpringMVC/SpringBoot

• 配套 通信方式：rpc
• 注册中心：zookeeper / redis
• 配置中心：diamond

只能实现治理中心，熔断等并不能实现

7.3.2、SpringCloud：全家桶+轻松嵌入第三方组件(Netflix)

• 配套 通信方式：http restful
• 注册中心：eruka
• 配置中心：config
• 服务的隔离及断路器：hystrix
• 网关：zuul
• 分布式追踪系统：sleuth + zipkin

关于SpringCloud全家桶可以参考我之前发布的文章SpringCloud超详细笔记（附源码）一文；

7.3.3、SpringCloud Alibaba

      Spring Cloud Alibaba是对Spring Cloud的标椎实现；他致力于提供微服务开发的一站式解决方案。此项目包含开发微服务架构的必需组件，方便开发者通过 Spring Cloud 编程模型轻松使用这些组件来开发微服务架构，只需要添加一些注解和少量配置，就可以将 Spring Cloud 应用接入阿里分布式应用解决方案，通过阿里中间件来迅速搭建分布式应用系统。

将在下篇中详细分享SpringCloud Alibaba以及他的环境的搭建；

自此常见系统架构的介绍、演变以及优缺点就分享到这里了，如有欠缺欢迎个位大佬在评论区批评指正！