自己化运维、容错、快速演进等特点，它可以解决传统项目的弊病，并且可以满足越来越复杂的业务关系。
二、单体架构和分布式架构的优缺点。
1）单体架构：
以MVC架构模式为例，我们在传统项目中基本都是采用这种方式。通过MVC（表示层、业务逻辑层、数据访问层）的架构基本能够所有应用程序。
缺点：
随着业务复杂性增加，代码量增加。代码的可读性、可维护性和可扩展性就会下降。
随着用户数量增加，并发数增加。单体项目的并发就会存在瓶颈。
测试难度增加。
为了解决上面的一些问题传统的方式：
通过nginx进行反向代理，做负载均衡，运用程序，多台部署。
MySQL设置主从，通过读写分理来改善并发能力。
通过加入缓存，提高读取效率。
但是这种方式还是会存在很大问题：
单体项目代码的可读性、可维护性和可扩展性还是不能提升。
随着海量用户增加，数据库将成为瓶颈。
交付能力越来越弱。新老人员维护代码的成本过高，代码修改添加成本太高。
2）分布式架构
微服务特点：
按业务划分为一个独立单元，即独立的服务。
服务通过http协议通讯。
自动化部署。
可以介于不同语言之间。
可以用不同的存储技术。
服务集中化管理。
是一个分布式系统。
优势：
通过把庞大的业务关系拆分成各个晓得单元，服务之间明确界限，增加了代码的可读性和可扩展性。
由于微服务系统是分布式系统，在业务扩展上面有很强的能力。另外并发能力，可以通过集群方式得以处理。
通过http协议传输数据，服务之间完全解耦。这使得服务之间可以通过不同语言开发。
如果存在部分架构调整，那么单体工程绝对是抓破头皮的存在。
微服务在进行更新或者戎机的情况下，不会影响其他服务。
在CAP理论中使用AP架构，及有具有高可用和分区容错的特点。
缺点：
复杂度高。由于是分布式系统，所以部署复杂、学习成本上升、网路问题、服务依赖、测试都会变得更加复杂。
分布式事务。CAP理论（即同时满足一致性(Consistency)、可用性(Availability)、分区容错(Partition tolerance)）。三者不可兼得，又由于P是基本要求所以，只能在CA中做取舍。微服务一般采用AP架构，那么问题就在一致性上面即分布式事务。一般采用两阶段提交方式解决。即第一阶段service-acount发起一个分布式事务，交给事务协调器TC管理。TC向所有参与事务的节点发起准备操作。第二阶段，如果准备成功，则发出提交命令，如果存在一个节点失败，则全部回滚。如果由于网络原因导致提交阻塞，会影响整个系统运行。所以尽量减少分布式事务的发生。
服务划分。业务拆分的界限主要是不是很明确，所以在划定上面一般根据业务的可独立和可更新进行划分。可以参考领域驱动设计进行划分。
服务部署。由于服务的数量和复杂度，还要考虑先后顺序等，所以导致了服务部署难的问题。目前采用的方式可以有docker编排，devops理念等
三、spring-cloud简介
1）微服务应该具备的功能
微服务具有以下特点：
按业务划分，代码量小，易于维护。
每个微服务有自己的独立组件。
通信采用http或者其他方式，具有容错能力。
一套服务治理方案，服务之间不耦合。
单个服务能够集群化，并且具有负载能力。
有一个完整的安全机制。
有链路追踪能力。
有一套完整的实时日志系统。
微服务具有以下功能：
服务的注册和发现。
服务的负载均衡。
服务的容错。（熔断器机制）
服务的网关。
服务配置的统一管理。
链路追踪。
实时日志。
2）简介
spring-cloud是基于spring-boot的。spring-boot是一种全新的web框架，他的特点是简化开发和部署过程。简化了spring的配置和依赖管理。spring-cloud是通过包装其他技术框架来实现的，提供了一些常用组件：服务注册与发现、配置中心、熔断器、智能路由、微代理、控制总线、全局锁、分布式会话等。
常用组件：
服务注册与发现组件：Eureka |
熔断组件：Hystrix |
| =====> Spring Cloud Netflix
负载均衡组件：Ribbon |
路由网关组件：Zuul |
Spring Cloud Config：配置文件统一管理功能，一般配合spring cloud bus（消息总线）使用
Spring Cloud Security：安全管理，一般配合spring security oauth2使用
Spring Cloud Sleuth：分布式链路追踪组件
Spring Cloud Stream：数据流操作包
其他组件：
Feign：声明式远程调度组件。
Archaius：配置管理API组件。
Spring Cloud Data Flow：大数据操作组件。
Spring Cloud Consul：另一个服务注册与发现组件。
Spring Cloud Zookeeper：服务注册与发现组件。
Spring Cloud CLI：可以让用户以命令形式快速运行和搭建容器。
Spring Cloud Task：任务调度和管理。
四、上面介绍了Spring Cloud，下面看一下阿里的Dubbo。
Dubbo是阿里开源的一个分布式服务架构，致力于高性能和透明化的RPC调用，以及SOA的服务治理方案。
1）RPC远程调用：以NIO为基础实现的Netty框架的使用。
2）集群容错：提供了基于接口方法的远程调用功能，并显示负载均衡、失败容错等功能。
3）服务发现与发现：集成Zookeeper。
4）Dubbo架构流程：
服务提供者向服务中心注册服务。
服务消费者订阅服务。
服务消费者发现服务。
服务消费者远程调度服务提供者进行服务消费，在调度过程中使用了负载均衡、失败容错等功能。
服务消费者和提供者，在内存中记录调用次数，并定时发送监控中心。
特点：
连通性：服务之间均为长连接。
健壮性：监控中心宕机不影响其他服务。
伸缩性：动态增减注册中心和服务数量。
升级性：服务集群升级，不会对现有框架造成压力。
五、Spring Cloud和Dubbo对比
目前Dubbo已经完全开源，捐给apache了，更新的状态不是很频繁。Dubbo使用tcp的协议，从效率上来说，比Spring Cloud的Restful的接口风格更快。Dubbo更好基于xml配置，Spring Cloud更多基于注解进行配置。上手层度上来说，Dubbo上手更加容易，Spring Cloud和Spring Boot的相关文档全都是英文且量大，所以学习成本上来说，Dubbo更好。但是从解耦上来说，Spring Cloud采用http通信，所以在解耦上面做的更好。开发效率和部署效率上来说，Spring Cloud做的更加完善和高效。
六、容器集群管理Spring Cloud和Kubernetes对比
总结：
Spring Cloud采用Java编写，在集成上面会更加实用。
Spring Cloud 有大量的类库。
Spring Cloud 更多关注功能点。
Kubernetes支持跨语言。
Kubernetes提供微服务功能外，还支持环境、资源限制、管理应用程序声明周期等功能。
Kubernetes面向DevOps人员。
Kubernetes学习成本高，比较新的平台。