什么是微服务架构
我们知道分布式强调系统的拆分，其实微服务也是强调系统的拆分，微服务架构属于分布式架构的范畴；
并且到目前为止，微服务并没有一个统一的标准的定义，那么微服务究竟是什么？
微服务一词源于Martin Fowler（马丁.福勒）的名为 Microservices 的博文， 可以在他的官方博客上找到这篇文章：http://martinfowler.com/articles/microservices.html
中文翻译版本：https://www.martinfowler.cn/articles/microservices.html
简单地说， 微服务是系统架构上的一种设计风格， 它的主旨是将一个原本独立的系统拆分成多个小型服务，这些小型服务都在各自独立的进程中运行，服务之间通过基于HTTP的RESTful API进行通信协作；
被拆分后的每一个小型服务都围绕着系统中的某一项业务功能进行构建， 并且每个服务都是一个独立的项目，可以进行独立的测试、开发和部署等； 由于各个独立的服务之间使用的是基于HTTP的JSON作为数据通信协作的基础，所以这些微服务可以使用不同的语言来开发；
微服务架构的优缺点
1、我们知道微服务架构是将系统中的不同功能模块拆分成多个不同的服务，这些服务进行独立地开发和部署，每个服务都运行在自己的进程内，这样每个服务的更新都不会影响其他服务的运行；
2、由于每个服务是独立部署的，所以我们可以更准确地监控每个服务的资源消耗情况，进行性能容量的评估，通过压力测试，也很容易发现各个服务间的性能瓶颈所在；
3、由于每个服务都是独立开发，项目的开发也比较方便，减少代码的冲突、代码的重复，逻辑处理流程也更加清晰，让后续的维护与扩展更加容易；
4、微服务可以使用不同的编程语言进行开发；
但是在系统架构领域关于微服务架构也有一些争论，有人倾向于在系统设计与开发中采用微服务架构实现软件系统的低耦合，被认为是系统架构的未来方向，Martin Fowler（马丁.福勒）也给微服务架构很高的评价；
同时，对微服务架构也有人持反对观点，他们表示：
1、微服务架构增加了系统维护、部署的难度，导致一些功能模块或代码无法复用；
2、随着系统规模的日渐增长，微服务在一定程度上也会导致系统变得越来越复杂，增加了集成测试的复杂度；
3、随着微服务的增多，数据的一致性问题，服务之间的通信成本等都凸显了出来；
所以在系统架构时也要提醒自己：不要为了微服务而微服务。
为什么选择Spring Cloud构建微服务
微服务一词是Martin Fowler（马丁.福勒）于2014年提出来的，近几年微服务架构的讨论非常火热，无数的架构师和开发者在实际项目中实践着微服务架构的设计理念，他们在微服务架构中针对不同应用场景出现的各种问题，也推出了很多解决方案和开源框架，其中我们国内的互联网企业也有一些著名的框架和方案；
整个微服务架构是由大量的技术框架和方案构成，比如：
服务基础开发 Spring MVC、Spring、SpringBoot
服务注册与发现 Netflix的Eureka、Apache的ZooKeeper等
服务调用 RPC调用有阿里巴巴的Dubbo，Rest方式调用有当当网Dubbo基础上扩展的Dubbox
分布式配置管理 百度的Disconf、360的QConf、淘宝的Diamond、Netflix的Archaius等
负载均衡 Ribbon
服务熔断 Hystrix
API网关 Zuul
批量任务 当当网的Elastic-Job、Linkedln的Azkaban
服务跟踪 京东的Hydra、Twitter的Zipkin等
但是在微服务架构上，几乎大部分的开源组件都只能解决某一个场景下的问题，所以这些实施微服务架构的公司也是整合来自不同公司或组织的诸多开源框架，并加入针对自身业务的一些改进，没有一个统一的架构方案；
所以当我们准备实施微服务架构时，我们要整合各个公司或组织的开源软件，而且某些开源软件又有多种选择，这导致在做技术选型的初期，需要花费大量的时间进行预备研、分析和实验，这些方案的整合没有得到充分的测试，可能在实践中会遇到各种各样的问题；
Spring Cloud的出现，可以说是为微服务架构迎来一缕曙光，有SpringCloud社区的巨大支持和技术保障，让我们实施微服务架构变得异常简单了起来，它不像我们之前所列举的框架那样，只是解决微服务中的某一个问题，而是一个解决微服务架构实施的综合性解决框架，它整合了诸多被广泛实践和证明有效的框架作为实施的基础组件，又在该体系基础上创建了一些非常优秀的边缘组件将它们很好地整合起来。
加之Spring Cloud 有其Spring 的强大技术背景，极高的社区活跃度，也许未来Spring Cloud会成为微服务的标准技术解决方案；
