微服务系统组件结构

SpringBoot

多个服务进程

Kafka

库存服务

Server

客户端的负载均衡

Zookeeper

Api

DataBase

镜像

微服务监控

App

VIP

微服务组

日志

注册

中央数据库集群

负载均衡，反向代理，动态上下线

应用层

Hystrix 服务治理

LVS

Redis Replicate

微服务架构，闭环异构，解耦合，基于客户端负载

支付

业务1 

微服务数据库集群

从服务列表中得到服务的地址

Tomcat

返回结果

数据层

通过客户端的负载，访问可用的服务

前端服务

1 传统单体服务中，一个接口(Controller)只是处理一种业务2 在微服务的设计中，同一个接口可以根据需要进行横向扩展，或者部署多个项目3 也可能做服务的拆分，进行纵向扩展

Prometheus

hash（）

服务注册发现中心

Nginx

NetFlix Eureka

热点数据，bloom过滤器，Session共享

Set Key

。。。

Nginx服务组件

域名静动态分割

Thymeleaf Html

消息集群

Netflix Feign

服务列表

Redis Cluster

业务3

网关

用户

他们之间也会通过服务注册中心调用彼此

Redis Master

获取微服务提供服务后

这里的每种服务提供，可能都是一组应用

一致性HASH算法

产品

服务注册发现

1 网关可以拦截请求，做负载和分发，根据用户访问的地址，定位到对应的业务接口2 还可以做权限验证的功能

Ribbon

负载均衡，反向代理

入口层

异步消息缓冲

动态接入层

域名服务

Get Key

Eureka

分布式协调服务

将结果返回给用户

KeepAlived

Netflix Zuul

业务2 

负载均衡

协调层

数据分界，集群，缓存热点

微服务应用

缓冲消费

FastDFS

缓冲层

订单服务

商品服务

分布式监控 Prometheus

动态：ipsos.cn

静态层

静态：static.ipsos.cn

实际上，能真正落地微服务架构的并不多1 成本高：微服务的搭建有句话叫使用微服务，处处微服务，所有的功能点都是集群分布式的，不论从资源还是人员，是需要技术部门有一定体量的2 专业运维：整个框架的搭建，不但从资源规划，网络链路，环境配置，软件特性等方面综合考虑，而且要对相关的技术栈有丰富的经验，踩过无数的坑。这里要明确一定，开发和运维是2个不同的专业，部署软件环境本身就是运维的工作，开发指所以也要懂，毕竟学习技术的过程要有测试的环境，但保证环境的稳定这不是开发的责任，另外就是企业体量不够，一个人当2角色来用，造成了这种现状。3 改造困难多：基本上可以排除从0开发的可能，毕竟这个概念出来也没几年，几乎都是将现有的系统进行改造，这个过程是比较漫长且问题不断的，很多都改到一半都进行不下去了。毕竟业务部不能停，并行开发风险高。而且跟风不可取，并不是都有必要拆成微服务。

获取服务列表

缓存层

远程服务调用

Json

consul

用户上传下载文件

一致性锁，协调服务