一，官方定义

1、一些列的独立的服务共同组成系统

2、单独部署，跑在自己的进程中

3、每个服务为独立的业务开发

4、分布式管理

5、非常强调隔离性

二，要实际的应用微服务，需要解决一下四点问题：

1、客户端如何访问这些服务

2、每个服务之间如何通信

3、如此多的服务，如何实现？

4、服务挂了，如何解决？（备份方案，应急处理机制）

客户端访问服务模型

三，一般在后台N个服务和UI之间一般会一个代理或者叫API Gateway

① 提供统一服务入口，让微服务对前台透明

② 聚合后台的服务，节省流量，提升性能

③ 提供安全，过滤，流控等API管理功能

 

 

四，如此多的服务，如何实现，即如何管理，服务之间如何感知变化，协调的协议。

基本都是通过zookeeper等类似技术做服务注册信息的分布式管理

在微服务架构中，一般每一个服务都是有多个拷贝，来做负载均衡。

1服务之间如何相互感知？服务如何管理？这就是服务发现的问题了。一般有两类做法，也各有优缺点。基本都是通过zookeeper等类似技术做服务注册信息的分布式管理。

2注册到ZK（或类似框架），并通过心跳维持长链接，实时更新链接信息。服务调用者通过ZK寻址，根据可定制算法， 找到一个服务，还可以将服务信息缓存在本地以提高性能。

当服务下线时，ZK会发通知给服务客户端。

 

客户端做：优点是架构简单，扩展灵活，只对服务注册器依赖。缺点是客户端要维护所有调用服务的地址，有技术难度，一般大公司都有成熟的内部框架支持，比如Dubbo。

服务端做：优点是简单，所有服务对于前台调用方透明，一般在小公司在云服务上部署的应用采用的比较多。

 

 

五，服务挂了，如何解决

①重试机制

②限流

③熔断机制

④负载均衡

⑤降级（本地缓存）

 

 

微服务架构需要考虑的问题：

1、API Gateway 代理；

2、服务间调用 服务之间通信方式

3、服务发现 服务之间协调方式

4、服务容错 备份/可靠性

5、服务部署 部署/便捷性

6、数据调用 速度，效率，安全性