浅谈springcloud入门（一）

随着互联网的发展壮大，我们所经历的项目开始变得丰富多彩，软件应用的体量越来越庞大和复杂，这就造成我们传统的单体应用可能不足以支撑大数据量以及高并发场景,应用的架构也随之进行演变，所以架构也开始由简单的单体应用架构到分布式架构再进一步到SAO架构，以及我们现在所使用的微服务架构。

架构的演变

目前我们工作所常使用的架构往往是微服务架构，当项目规模较大，用户体量，并发较大的时候，微服务总体性能占优势，所以我们应该根据项目类型以及项目规模来决定应用架构的选型；但是微服务架构往往成本过高，如大型电商、物流、售票等系统我们可以选择使用微服务架构，对于中小型的企业级应用我们依然可以选择单体架构。

单体架构

单体架构，就是所有的模块，组件等都在一个应用中应用最终打成一个war/jar包使用一个容器/Tomcat进行部署，通常一个应用享用一个数据库。这种架构成本比较低，也易于开发和部署环境，但是存在着高并发和高可用两大问题。下面我们仔细谈谈单体架构的优劣势，以便于有个全面的了解。

单体架构的优点：
- 易于开发 ：架构简单，技术成本低
- 易于测试 ：所有功能在一个项目，方便测试
- 易于部署 ：一个Tomcat就可以实现部署，简单方便

缺点也很明显：

- 代码臃肿不方便开发维护，代码可读性差
- 系统扩展性能变差，牵一发而动全身
- 无法针对某一个业务做扩展，单一模块集群
- 对大数据量，高并发量的处理不占优势
- 模块、业务耦合度高

这也就造成我们的项目想进一步扩大，单体架构会为未来留下很大的隐患，首先我们一旦相对臃肿的代码进行简化，牵一发而动全身，我们需要将整个项目推倒重构，这不会是明智人所想看到的。其次一旦一个业务出了问题，它影响的会是这个全体；还有人们访问就只有一个项目的话，会造成当流量超过服务极限能力时，系统可能会出现卡死、崩溃的情况，故全新的架构需求迫在眉睫，分布式架构应运而生。

高并发与高可用

• 架构之高并发：缓存
  • 高并发实现的三板斧：缓存，限流和降级。缓存在高并发系统中有者极其广阔的应用，需要重点掌握，本文重点介绍下缓存及其实现。
• 架构之高并发：限流
  • 每个系统都有服务的上线，所以当流量超过服务极限能力时，系统可能会出现卡死、崩溃的情况，所以就有了降级和限流。限流其实就是：当高并发或者瞬时高并发时，为了保证系统的稳定性、可用性，系统以牺牲部分请求为代价或者延迟处理请求为代价，保证系统整体服务可用。
• 架构之高并发：降级和熔断
  • 在高并发环境下，服务之间的依赖关系导致调用失败，解决的方式通常是: 限流->熔断->隔离->降级, 其目的是防止雪崩效应。
• 架构之高可用：负载均衡
  • 负载均衡（Load Balance），意思是将负载（工作任务，访问请求）进行平衡、分摊到多个操作单元（服务器，组件）上进行执行。是解决高性能，单点故障（高可用），扩展性（水平伸缩）的终极解决方案。
• 架构之高可用：容灾备份,故障转移
  • 容灾技术是系统的高可用性技术的一个组成部分，容灾系统更加强调处理外界环境对系统的影响，特别是灾难性事件对整个IT节点的影响，提供节点级别的系统恢复功能。故障转移（failover），即当活动的服务或应用意外终止时，快速启用冗余或备用的服务器、系统、硬件或者网络接替它们工作。故障恢复是在计划内或计划外中断解决后切换回主站点的过程。

分布式/SAO架构

根据业务进行拆分，把拆分出来的业务变成一个单体应用，每个应用都是一个单体架构，应用就只需要关注自己的业务即可，应用之前通过API相互调用，这样的架构就是分布式架构。

与其功能十分相同的是SAO架构，SOA架构是基于分布式架构演变的，面向服务的架构，简单理解SOA就是将分布式架构分为了服务层、表现层两个工程。

在看分布式架构的过程中，有些人会想到集群来解决高并发的，那么我们看看集群与分布式的区别？

简而言之，集群就是复制，它将单体项目进行复制多个相同的应用一起工作来提高作业能力，多个应用做的是相同的事情；分布式则是将一种业务拆分成其他的部分业务分布在多台服务器上。

分布式的优点与缺点：

优点

- 解耦合、系统之间用接口通信
- 项目拆分，不同的团队负责不同的子项目
- 利于扩展，增加功能，只需增加子项目，调用其他系统接口就好了
- 可以灵活的进行分布式部署

缺点
 - 各系统之间交互需要远程通信，接口开发增加工作量
 - 各系统之间的通用业务代码无法进行公用

SOA
   优点
    - 模块拆分，使用API通信，降低模块之间的耦合度
    - 项目拆分多个子应用，每个子应用业务简单，代码简单，方便维护开发
    - 不同技术人员可以负责不同的子应用
    - 提高服务之间的重用性，业务逻辑可组合
   缺点
    - 服务之间的API接口开发增加了工作量
    - SOA服务之间的网络通信调用对性能有一定的影响，影响很小
    - 相对于单体应用来说，技术、人力成本较高
    - 部署和运维相对麻烦
    - 服务的划分细粒度过于粗，无法针对某一业务进行弹性扩展
    - 相比起微服务架构，敏捷开发能力弱

微服务架构

微服务是在SOA上做的升华，微服务架构强调的一个重点是业务需要彻底的组件化和服务化，原有的单个业务系统会拆分为多个可以独立开发、设计、运行的小应用，这些小应用之间通过服务完成交互和集成。

优点
    - 单个服务业务简单，代码简单方便开发维护
    - 服务之间无耦合，服务之间升级维护互不影响
    - 轻量级HTTP通信机制，使得的不同的服务可以采用不同的编程语言，支持异构
    - 微服务有极强的扩展能力，业务量大的服务可以再次拆分服务，也可以进行集群部署，剔除服务也很方便
    - 更大的系统负载能力和容错能力，部署集群
    - 微服务架构对现在流行的敏捷开发支持较好

缺点
    - 部署麻烦 ：微服务众多，部署麻烦，需要借助容器技术和自动化部署工具，这又增加了开发人员的学习成本
    - 技术成本高  ：微服务架构本身比较复杂，技术成本高，开发人员需要花更多的时间学习相关技术
    - 服务通信对性能的损耗：微服务架构一定要考虑服务通信延迟对服务调用性能的损耗问题，开发人员需要选择合适的通信方式解决这一问题