一、微服务架构文述

微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调，互相配合，为用户提供最终价值。每个服务运行在其段都的进程中，服务与服务之间采用轻量级的通讯机制互相协作（通常是基于HTTP协议的RESTful API）。每一个服务都围绕着具有本业务进行构建，并且能够被独立的部署到生成环境、类生成环境等。另外，应当尽量避免统一、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选着合适的语言、工具对其构建。

一个微服务架构，有很多组件相互协调相互配合进行这个业务的服务与服务直接的联系，如：服务注册与发现、服务调用、服务熔断、负载均衡、服务降级、服务消息队列、配置中心管理、服务网关、服务监控、全链路追踪、自动化构建部署、服务定时任务调度操作等

二、微服务的特征

1、每个微服务可独立运行在自己的进程里；
2、一系列独立运行的微服务共同构建起了整个系统；
3、每个服务为独立的业务开发，一个微服务一般完成某个特定的功能，比如：订单管理、用户管理等；
4、微服务之间通过一些轻量的通信机制进行通信，例如通过REST API或者RPC的方式进行调用。

三、微服务架构的优势与不足

扩展阅读：微服务的优势与不足 http://dockone.io/article/394

1、微服务的好处

1、因为是服务分开，解决了单体项目庞大不好维护，不好理解的问题
2、这种结构使得每个服务都可以有专门开发团队来开发。开发者可以只有选择开发技术，提供API服务
3、微服务架构是每个微服务服务独立的部署，开发者不再需要协调其他服务部署对本服务的影响
4、微服务架构模式使得每个服务独立扩展。开发者可以根据每个服务的规模来部署满足需求的规模。甚至于，开发者可以使用更适合于服务资源需求的硬件。比如，你可以在
EC2 Compute Optimized instances上部署CPU敏感的服务，而在EC2 memory-optimized instances上部署内存数据库。

2、微服务的不足

1、微服务应用是分布式系统，由此会带来固有的复杂性。开发者需要在RPC或者消息传递之间选择并完成进程间通讯机制。
2、关于微服务的挑战是来自于分区的数据库架构。商业交易中同时给多个业务分主体更新消息很普遍。这种交易对于单体式应用来说很容易，因为只有一个数据库。在微服务架构应用中，需要更新不同服务所使用的不同的数据库。
3、测试一个基于微服务架构的应用也是很复杂的任务。比如，采用流行的SpringBoot架构，对于一个单体式web应用，测试他的REST API，是很容易的事情。反过来，同样的服务测试需要启动和它相关所以服务（至少需要这些服务的stubs）。不能低估了采用微服务架构带来的复杂度
4、部署

四、单体式应用的不足

单体式应用做项目很简单，不管是接口的编写，测试，部署，等等都很方便。
但是，这种简单的单体式却有很大的局限性。一个简单的应用会随着时间和义务的扩展逐渐变大，最后小而简单的应用会变成一个巨大的怪物。经过多少程序员多年努力培养的一个怪物。
1、在业务还有时间的推移，项目的复杂度越来越大，模块与模块之间耦合也越来越大，项目也从简单变向复杂
2、单体式应用降低开发速度。应用越大，启动时间会越长。有的应用可能启动都需要花费40分钟的时间！如果开发者需要经常重启应用，那么大部分时间就要在等待中渡过，生产效率收到极大影响。
3、复杂而巨大的单体式应用也不利于持续性开发
4、单体式应用在不同模块发生资源冲突时，扩展将会非常困难。
5、单体应用另外一个问题就是可靠性。因为所有模块都运行在一个进程中，任何一个模块中的一个bug，比如内存泄漏，将会有可能整垮整个进程。
6、单体式应用使得采用新架构和语言非常困难。比如，设想你有两百万行采用XYZ框架写的代码。如果想改成ABC框架，无论式时间还是成本都是非常昂贵的，即使ABC框架更好。因此，这是一个无法逾越的鸿沟。你不得不在最初选择面前低头

总结一下：一开始你有一个很成功的关键业务应用，后来变成了一个巨大的、无法理解的怪物。因为采用过时的、效率低的技术，使得雇佣有潜力的开发者很困难。应用无法扩展，可靠性很低，最终，敏捷性开发和部署变得无法完成。

五、SpringCloud的解释

SpringCloud是分布式微服务架构的一站式解决方案。是多种微服务架构落地技术的集合体，俗称微服务全家桶。
下图是官网的一个简单的图文说明，其实SpringCloud不是一个一个技术，而是很多种技术集合成一种解决方案：

六、SpringCloud技术栈

1、各个技术栈功能介绍

目前通用常用的微服务架构：

如下面几个核心常用组件：（其中也有些组件慢慢的因为停止更新被其他组件慢慢替代）