1、微服务概述

1、单体架构

​

单体应用比较容易部署、测试，在项目的初期，我们往往会把所有的业务功能放在一个应用里。

但是随着业务的需求的发展，功能的不断增加，单体架构就暴露了很多的问题：

1、可维护性差：模块非常多、模块的边界模糊、依赖关系不清楚、代码混乱的堆砌在一起，模块之间的耦合度过高，整个项目变的非常复杂。代码不易于阅读、难以修改，修改一个bug可能会导致很多连锁的bug。如果不出问题，开发人员是不会愿意去修改和优化原有的代码，即使这个开发人员很有追求。

2、开发部署问题：每一个功能的变更和缺陷的修复都必须重新部署整个应用。全量部署的方式影响范围大、风险高。所以每次部署，都必须做回归测试，这是非常浪费时间的。项目启动速度慢，也影响开发的效率。

3、可靠性差：某个模块出现了严重的bug，比如：内存泄露 等，那么可能导致整个应用的崩溃。

4、无法按需伸缩: 无法根据业务模块的需要进行伸缩。比如：订单模块需要高并发，要加机器，我们就必须给整个单体进行加机器。商品模块有推荐功能，需要强劲的cpu和大量的内存进行计算，就需要给每台服务器提升cpu和内存。

5、技术问题：单体架构往往会采用统一的技术方案解决所有的问题。很难按照模块本身的特性，采用不同的技术解决，比如随着订单的增多，订单表需要分库分表，这时候就需要更换整个底层的技术。如果想采用更好的技术去重构项目，也是非常困难的。

所以，单体架构很难满足互联网时代业务快速变化的需求。

2、微服务架构

微服务架构实际上是将一个单体应用按照功能模块拆分为一个个独立运行的的服务。

微服务架构有如下几个特性：

1. 每个微服务可独立运行在自己的进程里；

2. 一系列独立运行的微服务共同构建起了整个系统；

3. 每个服务为独立的业务开发，一个微服务一般完成某个特定的功能，比如：订单管理，用户管理等；

4. 微服务之间通过一些轻量级的通信机制进行通信，例如通过REST API或者RPC的方式进行调用。

优点：单体架构的缺点，基本上是微服务的优点。

缺点：服务越来越多，必然会增加运维的要求，给运维带来了很大的挑战。

划分：服务的划分会借鉴领域驱动设计的思想，以及结合自身的业务进行划分。比如用户的登录/注册（用户服务），网站上展示商品的管理（商品服务），商品购买后的订单（订单服务）以及支付（支付服务）等等。应用层根据用户行为，协调领域层的服务，完成一个个具体的应用服务提供给客户端。领域层的服务一般是细粒度的原子服务，所以领域服务与领域服务之间不应该相互调用，涉及到多个领域之间共同完成的功能，都应该放到应用层去协调完成。

3、技术选择

Spring Cloud为开发人员提供了快速构建分布式系统中一些常见模式的工具（例如配置管理，服务发现，断路器，智能路由，微代理，控制总线）。使用Spring Cloud开发人员可以快速地支持实现这些模式的服务和应用程序。

spring提供的常用工具：

1、服务的注册中心Netflix Eureka：服务的提供者会向注册中心注册自己的服务，服务消费者会从注册中心获取调用服务的服务地址列表，采用负载均衡算法选择一个服务进行调用。

2、服务网关Netflix Zuul：微服务网关封装了应用程序内部的服务，客户端只需要和网关打交道，而无需直接调用特定微服务的接口。

3、配置中心Spring Cloud Config：一个微服务应用架构，可能存在成百上千个微服务，因此集中管理配置是非常有必要的。

4、容错处理Netflix Hystrix：A调用B接口，在固定时间内，B接口调用超时比率达到一个阈值，会开启熔断。进入熔断状态后，后续对该服务接口的调用不再经过网络，直接执行本地的默认方法，达到服务降级的效果。

5、分布式追踪Spring Cloud Sleuth： 服务之间通过网络通信，如果能够追踪到每个请求，了解请求经过哪些微服务、请求耗费时间、网络延迟、业务逻辑、业务逻辑耗费时间等，那么就可以更好的分析系统瓶颈、解决系统问题。

以上简单的介绍了Spring Cloud提供的工具，除了上面的工具外，Spring Cloud还有提供了很多其他的工具，详细可查看官网：http://projects.spring.io/spring-cloud 。

alibaba springcloud的开源项目正在孵化中，可以关注一下

https://github.com/spring-cloud-incubator/spring-cloud-alibaba