为什么要用springcloud?
本文内容纲要：
-为什么要用springcloud?
-什么是微服务架构
-系统架构的演变过程
为什么要用springcloud?
在回答这个问题之前我们要了解什么是微服务架构，以及这些年系统架构的演变过程
什么是微服务架构
“微服务”一词源于MartinFowler的名为Microservices的博文，简单地说，微服务是系统架构上的一种设计风格，它的主旨是将一个原本独立的系统拆分成多个小型服务，这些小型服务都在各自独立的进程中运行，服务之间通过基于HTTP的RESTfulAPI进行通信协作。被拆分成的每一个小型服务都围绕着系统中的某一项或一些耦合度较高的业务功能进行构建，并且每个服务都维护着自身的数据存储、业务开发、自动化测试案例以及独立部署机制。由千有了轻量级的通信协作基础，所以这些微服务可以使用不同的语言来编写。
系统架构的演变过程
架构原始阶段：万能的单机
架构的最原始阶段，即一台服务器搞定一切。传统官网、论坛等应用，只需要一台。对应的web服务器、数据库、静态文件资源等，部署到一台服务器上即可。一般5万pv到30万pv访问量，结合内核参数调优、web应用性能参数调优、数据库调优，基本上能够稳定的运行。
架构动静分离阶段：静态缓存+文件存储
//nginx动静分离
server{
listen80;
server_nameds.oldxu.com;
location/{
proxy_passhttp://127.0.0.1:8080;
}
location~*\.(png|gif|jpg|mp4)${
root/images;
expires1d;
}
}
当访问压力达到100万pv到300万pv的时候，我们看到前端web服务出现性能瓶颈。大量的web请求被堵塞，同时服务器的CPU、磁盘IO、带宽都有压力。这时候我们一方面将网站图片、js、css、html及应用服务相关的文件存储在oss中，另外一方面通过CDN将静态资源分布式缓存在各个节点实现“就近访问”。通过将动态请求、静态请求的访问分离（“动静分离”），有效解决服务器在磁盘IO、带宽方面的访问压力。
架构分布式阶段：业务拆分负载均衡
当访问量达到1000万pv到5000万pv，虽然“动静分离”有效分离了静态请求的压力，但是动态请求的压力已经让服务器“吃不消”。最直观的现象是，前端访问堵塞、延迟、服务器进程增多、cpu100%，并且出现常见502/503/504的错误码。显然单台web服务器已经满足不了需求，这里需要通过负载均衡技术增加多台web服务器（对应ECS可以选择不同可用区，进一步保障高可用）。因而告别单机的时代，转变分布式架构的阶段。
虽然这个时候我们可以看到通过分布式文件系统OSS已经解决了文件存储的性能问题，CDN也已经解决静态资源访问的性能问题。但是当访问压力再次增加，这个时候web服务器和数据库方面依旧是瓶颈。在此我们通过垂直扩展，进一步切分web服务器和数据库的压力，解决性能问题。
在业务层，可以把不同的功能模块拆分到不同的服务器上面进行单独部署。比如，用户模块、订单模块、商品模块等，拆分到不同服务器上面部署。在数据库层，当结合数据库缓存，数据库压力还是很大的时候。我们通过读写分离的方式，进一步切分及降低数据库的压力。
结合业务拆分、读写分离，在数据库层，比如我们同样可以把用户模块、订单模块、商品模块等。所涉及的数据库表：用户模块表、订单模块表、商品模块表等，分别存放到不同数据库中，如用户模块库、订单模块库、商品模块库等。然后把不同数据库分别部署到不同服务器中。
当访问量达到5000万pv及以上时，真达到千万级架构以上访问量的时候，我们可以看到垂直扩展的架构也已经开始“山穷水尽”。比如，读写分离仅解决“读”的压力，面对高访问量，在数据库“写”的压力上面“力不从心”，出现性能瓶颈。另外，分库虽然将压力拆分到不同数据库中。但单表的数据量达到TB级别以上，显然已经达到传统关系型数据库处理的极限。
当前主流架构面临的问题
- 由于单体系统部署在一个进程内，功能模块之间耦合性强相互影响。
应用中的这些功能模块的使用场景、并发量、消耗的资源类型都各有不同，这样使得我们对各个业务模块的系统容量很难给出较为准确的评估。 - 随着系统功能越来越复杂，相应的应用也不断增加，我们的静态配置就会变得越来越难以维护。并且面对不断发展的业务，我们的集群规模、服务的位置、服务的命名等都有可能发生化，如果还是通过手工维护的方式，那么极易发生错误或是命名冲突等问题。同时，对于这类静态内容的维护也必将消耗大量的人力。
- Nginx等设施的路由实现负载均衡需要运维人员需要手工维护这些路由规则与服务实例列表，当有实例增减或是IP地址变动等情况发生的时候，也需要手工地去同步修，果当系统规模不断增大，那么这些看似简单的维护任务会变得越来越难，并且出现配置错误的概率也会逐渐增加。
- 单体应用中都实现一套校验逻辑。随着服务规模的扩大，这些校验逻辑的冗余变得越来越多，给开发和测试人员都造成困扰。
springCloud
SpringCloud项目不同于其他Spring的优秀项目，它不再是一个基础框架类，而是
一个更高层次的、架构视角的综合性大型项目，其目标旨在构建一套标准化的微服务解决
方案，让架构师、开发者在使用微服务理念构建应用系统的时候，面对各个环节的问题都
可以找到相应的组件来处理。引用网友戏称的一个比喻：SpringCloud可以说是Spring社
区为微服务架构提供的一个
“全家桶”套餐。由于“套餐”中的组件通过一个社区进行包
装与整合，使得“套餐”中各个组件之间的配合变得更加和谐，这可以有效减少我们在组
件的选型和整合上花费的精力，所以它可以帮助我们快速构建起基础的微服务架构系统。
考虑SpringCloud的原因有如下几点：
- SpringCloud来源于Spring，质量、稳定性、持续性都可以得到保证。
- spirngCloud天然支持SpringBoot，更加便于业务落地。
- SpringCloud是Java领域最适合做微服务的框架。相比于其它框架，SpringCloud对微服务周边环境的支持力度最大。对于中小企业来讲，使用门槛较低。
- SpringCloud是微服务架构的最佳落地方案。
- 与分布式系统相关的复杂性–包括网络问题，延迟开销，带宽问题，安全问题。
- 处理服务发现的能力–服务发现允许集群中的进程和服务找到彼此并进行通信。
- 解决冗余问题–冗余问题经常发生在分布式系统中。
- 负载平衡–改进跨多个计算资源（例如计算机集群，网络链接，中央处理单元）的工作负载分布。
- 减少性能问题–减少因各种操作开销导致的性能问题。
SpringCloud
本文内容总结：为什么要用springcloud?，什么是微服务架构，系统架构的演变过程，
原文链接：https://www.cnblogs.com/tomky/p/13030703.html