所谓微服务简单理解就是SOA架构下的最终产物，该架构的设计目标是为了肢解业务，使得服务能够独立运行。
微服务设计原则：
1、各司其职
2、服务高可用和可扩展性
在以往的单体应用时代 应用程序就是一个项目 在一个进程里运行
以电商系统为例
这种架构的特点是
1.开发简单，集中管理没有分布式的损耗
2.不好维护，升级困难 无法快速迭代
但是随着业务逻辑复杂度的提升,用户的累积，数据量的提升，数间的推移，并发量的提升 这种单体架构可能无法满足业务的需要，也就是常说的 系统扛不住了
于是便对系统进行了一个垂直拆分
这样做的优点是 垂直拆分 独立部署 但是拆分的越多 存储越复杂 系统间的冗余也越来越多 其实这个时候 我们还是单体架构 因为 订单这个业务 从头到尾 都是由一个进程来完成的
可以这么理解 单体架构是调用方法 bll => dal
但是到了分布式的构架 调用的就是服务 例如上图 把各个系统公用的一些东西(用户服务,支付，日志等) 抽离出来 部署在一个单独的服务里 各个服务之间完全隔离 各司其职
这种就可以称为分布式服务
分布式服务有以下特点
1.由一系列服务组装而成
2.各司其职 独立部署 独立运行
3.兼容不同语言 独立开发 独立维护
5.分布式管理
6.强调隔离性
随着分布式架构技术的不断成熟，设计系统架构时便会以服务拆分为手段，这就是微服务。
微服务架构本身是一种概念，是一种设计风格，旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦
概念 ：把一个大型的单体应用程序和服务拆分为数个甚至数十个的支持微服务，它可以拓展单个组件而不是整个的应用程序堆栈从而满足服务等级协议
但是上面图里有一个地方 大家看着一定很不舒服
这才是一个合理的微服务架构
Geteway : 网关
它的作用是什么呢
1.提供统一的服务入口,让微服务对前台透明
2.聚合后台业务，节省流量，提升性能(这不是一个主流的功能，或者说这并不是一个好事，但它确实是微服务的一个功能)
3.提供 安全(Authentication/Authorization)，过滤 留空等api管理功能
在我们有了网关之后 各个服务之间是怎么通信的呢，一般是有一下三种方式
1.利用第三方共享存储(Redis/DB/Queue/硬盘文件)
特点是
1.被动式通信
2.门槛低
2.服务通信(WebService/WebApi/WCF甚至ashx,aspx) 主流
特点是
1.主动触发
2.数据序列化传输
3.跨平台 平语言
4.http穿透防火墙
3.RPC - Remote Procedure Call
.Net Remote : .Net平台独有的 不支持跨平台
gRPC：高性能，开源和通用的RPC框架，面向服务端和移动端，基于http/2设计
服务治理
设想下假如上图中支付服务的服务器挂掉了 那我们几乎整个系统都瘫痪了 所以微服务时代 每个服务都应该是集群架构 (多实例)
其中的consul （服务治理） 的作用：
1.负载均衡(ServerLoadBalance)
2.服务注册与发现(Register/Discover)
3.健康检查（Health Check）
Polly 服务应急(熔断，降级，限流)
降级说白了就是对某个服务降低优先等级
熔断 拦截请求
Butterfly 跟踪
跟踪请求流程
Exceptionless：日志收集分析框架
Docker ：容器化部署 快速迭代 持续交付
Kubernetes：管理云平台中多个主机上的容器化的应用