Spring Cloud搭建微服务架构----前言

前言

每一个微服务都是六边形应用，都有本身的业务逻辑和适配器。服务之间经过API互相通讯，提供接口供客户端使用。每一个实例多是一个云VM或者是Docker容器。

以前的web应用拆分红一系列简单的服务应用。拆分以后能够对不一样用户，不一样设备，不一样场景进行自行部署。

微服务之间经过REST API或者MQ异步方式通讯，供外网使用的API，经过Gateway来传递信息。

微服务的拆分，不像传统多个服务共享一个数据库，微服务架构每一个服务都有本身的数据库，每种服务均可以有本身适合的数据库类型。

微服务好处

1. 分解了单体应用提供多个服务的复杂性问题，拆分以后每一个服务都有一个用RPC或是MQ或是API定义的边界。因为传统单体应用没有清晰的边界，存在开发，理解，维护，部署的复杂问题；
2. 每一个服务均可以有单独的团队维护开发，开发者客户选择本身擅长和合适的技术；
3. 每一个服务均可以独立部署，开发者不须要协调因其余服务调用，部署对本服务的影响。加快部署速度，更好的执行AB测试。持续部署变为可能。
4. 每一个服务均可以独立扩展。

微服务不足

1. 须要考虑和关心更多服务之间调用的问题。
2. 须要考虑多个服务的编排和依赖关系，包括开发和部署。
3. 多个服务的配置，部署，扩展，监控。

微服务的特征

1. 每一个服务仅仅对单个业务负责，这个业务也是这个服务的完整容量；
2. 每一个微服务均可以独立部署，不需依赖其余服务的相关资源，如数据库，内存缓存等；
3. 轻量级的通讯协议，如REST，AMQP等；
4. 服务具备可代替性，每一个服务原则上均可以被不一样的开发语言，开发框架进行技术实现，替换后不影响原有微服务对外提供的功能；
5. 每一个服务拥有本身独立的数据存储；
6. 每一个微服务由小的团队维护，服务以业务单元进行拆分；
7. 服务之间可经过组成聚合服务对外提供较粗粒度的服务功能；

微服务名词

• 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。