Vue：轻量级框架
只关注视图层，是一个构建数据的视图集合,大小只有几十kb
Vue.js通过简洁的API提供高效的数据绑定和灵活的组件系统
双向数据绑定
也就是所谓的响应式数据绑定。这里的响应式不是©media媒体查询中的 响应式布局，而是指vue.js会自动对页面中某些数据的变化做出同步的响应。
也就是说，vue.js会自动响应数据的变化情况，并且根据用户在代码中预先写好的绑定关系，对所有绑定在一起的数据和视图内容都进行修改。而这种绑定关系，就是以input标签的v-model属性来声明的，因此你在别的地方可能也会看到有人粗略的称vue.js为声明式渲染的模版引擎。
这也就是vue.js最大的优点，通过MVVM思想实现数据的双向绑定，让开发者不用再操作dom对象，有更多的时间去思考业务逻辑。
组件化
Vue.js通用组件，把一个单页应用中的各种模块拆分到一个一个单独的组件（component）中，我们只要先在父级应用中写好各种组件标签（占坑），并且在组件标签中写好要传入组件的参数（就像给函数传入参数一样，这个参数叫做组件的属性），然后再分别写好各种组件的实现（填坑）， 然后整个应用就算做完了。
视图,数据,结构分离
使数据的更改更为简单,不需要进行逻辑代码的修改，只需要操作数据就 能完成相关操作
虚拟D0M
现在的网速越来越快了，很多人家里都是几十甚至上百M的光纤，手机也是4G起步了，按道理一个网页才几百K,而且浏览器本身还会缓存很多资源文件，那么几十M的光纤为什么打开一个之前已经打开过，已经有缓存的页面还是感觉很慢呢？这就是因为浏览器本身处理D0M也是有性能瓶颈的，尤其是在传统开发中，用JQuery或者原生的JavaScript DOM操作函数对DOM进行频繁操作的时候，浏览器要不停的渲染新的DOM树，导致页面看起来非常卡顿。
而Virtual DOM则是虚拟DOM的英文，简单来说，他就是一种可以预先通过JavaScript进行各种计算，把最终的DOM操作计算出来并优化，由于这个DOM操作属于预处理操作，并没有真实的操作DOM,所以叫做虚拟D0M。最后在计算完毕才真正将D0M操作提交，将DOM操作变化反映到D0M树上。
运行速度更快
像比较与react而言，同样都是操作虚拟dom,就性能而言,vue存在很大的 优势
后端框架
使用 spring boot、spring cloud 开发。Spring Cloud 来源于 Spring, 利用Spring Boot进行快捷开发。由于目前Spring Cloud社区的维护和 支持的人员数量众多，相信Spring Cloud会有很好的发展。而且Spring Cloud基本上都是使用了现有的开源框架进行的集成，学习的难度和部署 的门槛就比较低，对于中小型企业来说，更易于使用和落地0 Spring Cloud 主要解决了什么问题？ 1、对于企业级的S0A框架来说，服务与服务间的解耦是一项巨大的难题，随着功能服务的不断增加，多服务间的相互调用频繁，调用过程就像一个杂乱无章的毛线球，很容易导致牵一发而动全身的情况，经常会由于在服务更新的过程中，没有合理通信，导致数据的丢失。
这时候就应该进行服务治理，将服务之间的直接依赖转化为服务对服务中心的依赖。Spring Cloud核心组件Eureka就是解决这类问题。
Eureka
Eureka是Netflix开源的一款提供服务注册和发现的产品，它提供了 完整的 Service Registry 和 Service Discovery 实现。也是 Spring Cloud 体系中最重要最核心的组件之一。
用大白话讲，Eureka就是一个服务中心，将所有的可以提供的服务都注册到它这里来管理，其它各调用者需要的时候去注册中心获取，然后再进行调用，避免了服务之间的直接调用，方便后续的水平扩展、故障转移等。
当然服务中心这么重要的组件一但挂掉将会影响全部服务，因此需要搭建Eureka集群来保持高可用性，生产中建议最少两台。
随着系统的流量不断增加，需要根据情况来扩展某个服务，Eureka内 部已经提供均衡负载的功能，只需要增加相应的服务端实例既可。那么在系统的运行期间某个实例挂了怎么办?Eureka内容有一个心跳 检测机制，如果某个实例在规定的时间内没有进行通讯则会自动被剔除 掉，避免了某个实例挂掉而影响服务。
Hystrix
在微服务架构中通常会有多个服务层调用，基础服务的故障可能会导致级联故障，进而造成整个系统不可用的情况，这种现象被称为服务雪崩效应。
服务雪崩效应是一种因“服务提供者”的不可用导致“服务消费者”的不可用，并将不可用逐渐放大的过程。
在这种情况下就需要整个服务机构具有故障隔离的功能，避免某一个服务挂掉影响全局。在Spring Cloud中Hystrix组件就扮演这个角色。
Hystrix会在某个服务连续调用N次不响应的情况下，立即通知调用 端调用失败，避免调用端持续等待而影响了整体服务。Hystrix间隔时间会再次检查此服务，如果服务恢复将继续提供服务。
Hystrix Dashboard 和 Turbine
当熔断发生的时候需要迅速的响应来解决问题，避免故障进一步扩散, 那么对熔断的监控就变得非常重要。
熔断的监控现在有两款工具：Hystrix-dashboard和Turbine
Hystrix-dashboard是一款针对Hystrix进行实时监控的工具，通过 Hystrix Dashboard我们可以直观地看到各Hystrix Command的请求响应时间，请求成功率等数据。
但是只使用Hystrix Dashboard的话，你只能看到单个应用内的服务信息，这明显不够。
我们需要一个工具能让我们汇总系统内多个服务的数据并显示到 Hystrix Dashboard, 这个工具就是 Turbine。
配置中心
随着微服务不断的增多，每个微服务都有自己对应的配置文件。在研发过程中有测试环境、UAT环境、生产环境，因此每个微服务又对应至少三个不同环境的配置文件。
这么多的配置文件，如果需要修改某个公共服务的配置信息，如：缓存、数据库等，难免会产生混乱，这个时候就需要引入Spring Cloud另外一个组件：Spring Cloud Config。
Spring Cloud Config
Spring Cloud Config是一个解决分布式系统的配置管理方案。它包含了Client和Server两个部分，Server提供配置文件的存储、以接口的形式将配置文件的内容提供出去，Client通过接口获取数据、并依据此数据初始化自己的应用。
其实就是Server端将所有的配置文件服务化，需要配置文件的服务实例去Config Server获取对应的数据。将所有的配置文件统一整理，避免了配置文件碎片化。
如果服务运行期间改变配置文件，服务是不会得到最新的配置信息，需要解决这个问题就需要引入Refresho它可以在服务的运行期间重新加 载配置文件。当所有的配置文件都存储在配置中心的时候，配置中心就成为了一个非常重要的组件。
如果配置中心出现问题将会导致灾难性的后果，因此在生产中建议对配置中心做集群，来支持配置中心高可用性。
上面的Refresh方案虽然可以解决单个微服务运行期间重载配置信息的问题，但是但是在真正的实践生产中，可能会有N多的服务需要更新配置。
如果每次依靠手动Refresh将是一个巨大的工作量，这时候Spring Cloud提出了另外一个解决方案：Spring Cloud Bus。
Spring Cloud Bus通过轻量消息代理连接各个分布的节点。这会用在广播状态的变化（例如配置变化）或者其它的消息指令中。
Spring Cloud Bus的一个核心思想是通过分布式的启动器对Spring Boot应用进行扩展，也可以用来建立一个或多个应用之间的通信频道。目前唯一实现的方式是用AMQP消息代理作为通道。
Spring Cloud Bus是轻量级的通讯组件，也可以用在其它类似的场景中。有了 Spring Cloud Bus之后，当我们改变配置文件提交到版本库中时，会自动的触发对应实例的Refresh,
服务网关
在微服务架构模式下，后端服务的实例数一般是动态的，对于客户端而言很难发现动态改变的服务实例的访问地址信息。
因此在基于微服务的项目中为了简化前端的调用逻辑，通常会引入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各个 服务上的监控数据，并提供查询接口。
总结
我们从整体上来看一下Spring Cloud各个组件如何来配套使用：
从上图可以看出Spring Cloud各个组件相互配合，合作支持了一套完整的微服务架构。
其中Eureka负责服务的注册与发现，很好将各服务连接起来
Hystrix负责监控服务之间的调用情况，连续多次失败进行熔断保护。
Hystrix dashboard, Turbine负责监控Hystrix的熔断情况，并给予图形化的展示
Spring Cloud Config提供了统一的配置中心服务
当配置文件发生变化的时候，Spring Cloud Bus负责通知各服务去获
取最新的配置信息
所有对外的请求和服务，我们都通过Zuul来进行转发，起到API网关
的作用
最后我们使用Sleuth+Zipkin将所有的请求数据记录下来，方便我们
进行后续分析
Spring Cloud从设计之初就考虑了绝大多数互联网公司架构演化所需
的功能，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数 据监控等。
这些功能都是以插拔的形式提供出来，方便我们系统架构演进的过程 中，可以合理的选择需要的组件进行集成，从而在架构演进的过程中会更加平滑、顺利。
825
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
