微服务

暂且用比较通俗的话说说对 微服务 的理解，至于专业的定义，以本人的水准，是定义不了的也没资格定义。

拿传统的JavaWeb应用来说，可能是单机版存储系统(MySQL/Oracle/SqlServer/…) + 处理所有业务的 Web应用 + 展示层。

这种传统的系统有个明显的特点就是所有业务处理都是集中在同一个应用甚至是同一个应用的同一个实例上的，称之为 单体应用。

而此处说的微服务的 微 字就是和 单体应用 相比较才表现出 微 的特性。

传统应用往往可以根据 不同业务 分解为 内部耦合性较高 的单独 模块 或者说是 子系统 亦或称之为 子服务。每个子模块负责一块相对独立的业务逻辑。各个模块运行于 同一机器的不同进程 中甚至 不同的机器上的不同进程 中。模块之间通过某种通信协议 (HTTP/RESTFul-API/RMI/RPC/…)通信，相互配合来共同提供对客户端的服务，这样一来就将 服务组件化 了。

当采用和底层语言无关的通信协议(HTTP/RESTFul-API)的时候，各个模块甚至可以用不同的语言来实现。当然也可以将各个模块做成高可用的。

以上所谓的分解，在一定角度上可以大概说明微服务的模糊轮廓了。但是在实际操作中会遇到许多其他问题，比如维护的复杂性上升了、分布式的事务处理等一些列头疼的问题。

这一概念被提出之后，一些列的落地的产品也相继诞生。比如阿里的Dubbo、由Dubbo衍生而来的DubboX、Apache的Consul等。

这里要说的 spring-cloud 可以时候是 微服务组件的全家桶。是由一大堆可插拔的组件组成的一个庞大的微服家族。加上 Spring 团队雄厚的技术实力，在众多的选择中没理由不选择Spring-Cloud。其他的可选解决方案和Spring-Cloud相比，要么不够成熟、难用、社区不够活跃、资料不够完备……。

spring-cloud特性

• 服务治理
• 分布式配置中心
• 分布式服务跟踪
• 负载均衡
• 容错保护
• 声明式服务调用
• 网关服务
• 消息总线