Spring Cloud与微服务学习总结（1）——Spring Cloud及微服务入门

一、Spring Cloud是什么鬼？

 Spring Cloud为开发者提供了快速建立一些常见的模式在分布式系统的工具（如配置管理、服务发现、断路器、智能路由、微代理，控制总线，一次性令牌，全球锁，领导选择，分布式会话集群状态）。分布式系统之间的协调导致锅炉板模式，开发人员使用Spring Cloud可以迅速地建立服务和应用程序来实现这些模式。这些模式在任何分布式环境下都能很好运行，其中包括开发人员使用的笔记本电脑，裸机数据中心，以及托管平台，如Cloud Foundry。

中文文档：https://springcloud.cc/

官方文档：http://projects.spring.io/spring-cloud/

二、谈Spring Cloud撇不开微服务

微服务并不神秘，只是在互联网技术发展过程中的一个产物，整个架构系统随着客户端的多样性，服务越来越多，devops的发展而产生的架构变种。
许多公司，通过采用微处理结构模式解决单体应用的问题，分解的服务之间互相连接提供支持。
每个微服务都是六边形应用，都有自己的业务逻辑和适配器。服务之间通过API互相通信，提供接口供客户端使用。每个实例可能是一个云VM或者是Docker容器。
之前的web应用拆分成一系列简单的服务应用。拆分之后可以对不同用户，不同设备，不同场景进行自行部署。
微服务之间通过REST API或者MQ异步方式通信，供外网使用的API，通过Gateway来传递信息。
微服务的拆分，不像传统多个服务共享一个数据库，微服务架构每个服务都有自己的数据库，每种服务都可以有自己适合的数据库类型。
微服务好处
分解了单体应用提供多个服务的复杂性问题，拆分之后每个服务都有一个用RPC或是MQ或是API定义的边界。由于传统单体应用没有清晰的边界，存在开发，理解，维护，部署的复杂问题；
每个服务都可以有单独的团队维护开发，开发者客户选择自己擅长和合适的技术；
每个服务都可以独立部署，开发者不需要协调因其他服务调用，部署对本服务的影响。加快部署速度，更好的执行AB测试。持续部署变为可能。
每个服务都可以独立扩展。
微服务不足
需要考虑和关心更多服务之间调用的问题。
需要考虑多个服务的编排和依赖关系，包括开发和部署。
多个服务的配置，部署，扩展，监控。
微服务的特征
每个服务仅仅对单个业务负责，这个业务也是这个服务的完整容量；
每个微服务都可以独立部署，不需依赖其他服务的相关资源，如数据库，内存缓存等；
轻量级的通信协议，如REST，AMQP等；
服务具有可代替性，每个服务原则上都可以被不同的开发语言，开发框架进行技术实现，替换后不影响原有微服务对外提供的功能；
每个服务拥有自己独立的数据存储；
每个微服务由小的团队维护，服务以业务单元进行拆分；
服务之间可通过组成聚合服务对外提供较粗粒度的服务功能；
微服务名词
Gateway：为客户端提供API管理功能，负责负载均衡，缓存，访问控制，API计费监控等任务，可通过Eureka或者NGINX实现；
服务注册于发现模块；
断路器；
微服务选型
Dubbo，DubboX（不再维护）；
Spring Cloud（集成框架）；
Motan；
Thrift，gRPC（算不上框架）；
本次主要使用Spring Cloud；
基础框架选择 Spring Cloud和Dubbo：
Dubbo：
国内影响力较大，实现了服务治理的基础，但是完成一个完备的微服务架构，还需要在各环节去扩展和完善以保证集群健康，文档较稳定。
Spring Cloud：
国外影响大，社区活跃度领先，将成熟框架融为一体，继承了Spring Boot的简单配置，快速开发，部署轻松特点，更新较快，文档有差异。
日志监控
由Docker通过Syslog日志驱动将日志写入Logstash，参照ELK解决方案。
Devops
使用Docker作为微服务交付标准组件。
集成Docker

通过Consul集成Docker。

来源：http://blog.csdn.net/u012562943/article/details/70318589