传统架构发展史
单体架构
单体架构在小微企业比较常见，典型代表就是一个应用、一个数据库、一个Web容器就可以跑起来，比如我们开发的开源软件云收藏，就是标准的单体架构。
在两种情况下可能会选择单体架构：一是在企业发展的初期，为了保证快速上线，采用此种方案较为简单灵活；二是传统企业中垂直度较高，访问压力较小的业务。在这种模式下对技术要求较低，方便各层次开发人员接手，也能满足客户需求。
下面是单体架构的架构图：
在单体架构中，技术选型非常灵活，优先满足快速上线的要求，也便于快速跟进市场。
垂直架构
在单体架构发展一段时间后，公司的业务模式得到了认可，交易量也慢慢的大起来，这时候有些企业为了应对更大的流量，就会对原有的业务进行拆分，比如说：后台系统、前端系统、交易系统等。
在这一阶段往往会将系统分为不同的层级，每个层级有对应的职责，UI层负责和用户进行交互、业务逻辑层负责具体的业务功能、数据库层负责和上层进行数据交换和存储。
下面是垂直架构的架构图：
垂直架构的架构图
在这个阶段SSH（Struts Spring Hibernate）是项目的关键技术，Struts负责Web层逻辑控制、Spring负责业务层管理Bean、Hibernate负责数据库操作进行封装，持久化数据。
服务化架构
如果公司进一步的做大，垂直子系统会变的越来越多，系统和系统之间的调用关系呈指数上升的趋势。在这样的背景下，很多公司都会考虑服务的SOA化。SOA代表面向服务的架构，将应用程序根据不同的职责划分为不同的模块，不同的模块直接通过特定的协议和接口进行交互。这样使整个系统切分成很多单个组件服务来完成请求，当流量过大时通过水平扩展相应的组件来支撑，所有的组件通过交互来满足整体的业务需求。
SOA服务化的优点是，它可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。服务层是SOA的基础，可以直接被应用调用，从而有效控制系统中与软件代理交互的人为依赖性。
服务化架构是一套松耦合的架构，服务的拆分原则是服务内部高内聚，服务之间低耦合。
下面是服务化架构图：
服务化架构图
在这个阶段可以使用WebService或者Dubbo来服务治理。
我们发现从单体架构到服务化架构，应用数量都在不断的增加，慢慢的下沉的就成了基础组建，上浮的就成为业务系统。从上述也可以看出架构的本质就是不断的拆分重构：分的过程是把系统拆分为各个子系统/模块/组件，拆的时候，首先要解决每个组件的定位问题，然后才能划分彼此的边界，实现合理的拆分。合就是根据最终要求，把各个分离的组件有机整合在一起。拆分的结果使开发人员能够做到业务聚焦、技能聚焦，实现开发敏捷，合的结果是系统变得柔性，可以因需而变，实现业务敏捷。
SOA和微服务架构
SOA和微服务的区别
其实服务化架构已经可以解决大部分企业的需求了，那么我们为什么要研究微服务呢？先说说它们的区别：
微服务架构强调业务系统需要彻底的组件化和服务化，一个组件就是一个产品，可以独立对外提供服务
微服务不再强调传统SOA架构里面比较重的ESB企业服务总线
微服务强调每个微服务都有自己独立的运行空间，包括数据库资源
微服务架构本身来源于互联网的思路，因此组件对外发布的服务强调了采用HTTP Rest API的方式来进行
微服务的切分粒度会更小
总结：微服务架构是 SOA 架构思想的一种扩展，更加强调服务个体的独立性、拆分粒度更小。
为什么考虑Spring Cloud
Spring Cloud来源于Spring，质量、稳定性、持续性都可以得到保证
Spirng Cloud天然支持Spring Boot，更加便于业务落地
Spring Cloud发展非常的快，从16年开始接触的时候相关组件版本为1.x，到现在将要发布2.x系列
Spring Cloud是Java领域最适合做微服务的框架
相比于其它框架,Spring Cloud对微服务周边环境的支持力度最大
对于中小企业来讲，使用门槛较低
Spring Cloud是微服务架构的最佳落地方案！
它的特性
以下为Spring Cloud的核心特性：
分布式/版本化配置
服务注册和发现
路由
服务和服务之间的调用
负载均衡
断路器
分布式消息传递
这些特性都是由不同的组件来完成，在架构的演进过程中扮演着重要的角色，接下来我们一起看看。
微服务架构
Spring Cloud解决的第一个问题就是：服务与服务之间的解耦。很多公司在业务高速发展的时候，服务组件也会相应的不断增加。服务和服务之间有着复杂的相互调用关系，经常有服务A调用服务B，服务B调用服务C和服务D……，随着服务化组件的不断增多，服务之间的调用关系成指数级别的增长，极端情况下就如下图所示：
服务网关
在微服务架构模式下，后端服务的实例数一般是动态的，对于客户端而言很难发现动态改变的服务实例的访问地址信息。因此在基于微服务的项目中为了简化前端的调用逻辑，通常会引入API Gateway作为轻量级网关，同时API Gateway中也会实现相关的认证逻辑从而简化内部服务之间相互调用的复杂度。
Spring Cloud体系中支持API Gateway落地的技术就是Zuul。Spring Cloud Zuul路由是微服务架构中不可或缺的一部分，提供动态路由，监控，弹性，安全等的边缘服务。Zuul是Netflix出品的一个基于JVM路由和服务端的负载均衡器。
它的具体作用就是服务转发，接收并转发所有内外部的客户端调用。使用Zuul可以作为资源的统一访问入口，同时也可以在网关做一些权限校验等类似的功能。
链路跟踪
随着服务的越来越多，对调用链的分析会越来越复杂，如服务之间的调用关系、某个请求对应的调用链、调用之间消费的时间等，对这些信息进行监控就成为一个问题。在实际的使用中我们需要监控服务和服务之间通讯的各项指标，这些数据将是我们改进系统架构的主要依据。因此分布式的链路跟踪就变的非常重要，Spring Cloud也给出了具体的解决方案：Spring Cloud Sleuth和Zipkin。
Spring Cloud Sleuth为服务之间调用提供链路追踪。通过Sleuth可以很清楚的了解到一个服务请求经过了哪些服务，每个服务处理花费了多长时间。从而让我们可以很方便的理清各微服务间的调用关系。
Zipkin是Twitter的一个开源项目，允许开发者收集 Twitter 各个服务上的监控数据，并提供查询接口
分布式链路跟踪需要Sleuth+Zipkin结合来实现。
总结
我们从整体上来看一下Spring Cloud各个组件如何来配套使用：
从上图可以看出Spring Cloud各个组件相互配合，合作支持了一套完整的微服务架构。
其中Eureka负责服务的注册与发现，很好将各服务连接起来
Hystrix负责监控服务之间的调用情况，连续多次失败进行熔断保护
Hystrix dashboard，Turbine负责监控Hystrix的熔断情况，并给予图形化的展示
Spring Cloud Config提供了统一的配置中心服务
当配置文件发生变化的时候，Spring Cloud Bus负责通知各服务去获取最新的配置信息
所有对外的请求和服务，我们都通过Zuul来进行转发，起到API网关的作用
最后我们使用Sleuth+Zipkin将所有的请求数据记录下来，方便我们进行后续分析
Spring Cloud从设计之初就考虑了绝大多数互联网公司架构演化所需的功能，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等。这些功能都是以插拔的形式提供出来，方便我们系统架构演进的过程中，可以合理的选择需要的组件进行集成，从而在架构演进的过程中会更加平滑、顺利。
微服务架构是一种趋势，Spring Cloud提供了标准化的、全站式的技术方案，意义可能会堪比当前Servlet规范的诞生，有效推进服务端软件系统技术水平的进步。
