微服务
定义：
它是一种架构模式，提倡将大的单体系统，按业务拆分成一个个较小且独立的服务，服务与服务之前进行相互协作和配合。
历史：
针对互联网行业的蓬勃发展，需要支撑的业务越来越多，越来越大，单体程序越来越难以支撑，因此才出现了微服务的这种架构。
优点：
它的优点主要是与单体程序相比
1.开发独立：因开发独立就可以使用不同的语言进行开发，这样就更能发挥出各语言擅长的方面。
2.低耦合 ：服务与服务间采用轻量级的通信机制相沟通（Http，tcp/id），当某一服务出现问题，可以通过“降级熔断”等手段来保证系统不雪崩。
3.独立部署：这个就厉害了，独立部署带给我们的就是快速的迭代，完全与现在的敏捷开发相符。
4.横向扩展：这就是对于某一个服务的压力大的时候，我们就可以针对这一个服务进行集群扩展，而不像原单体系统那样，需要整个系统作扩展。
缺点：
1.因架构使各服务（系统）的颗粒度更小了，整体来说对开发和维护的难度就增加。（当然现在以云的方式部署，因此能屏蔽一些问题）
2.因服务与服务之前的通信机制是网络的方式，因此对于单体的进程内通信就显得运行效率降下来了。
原则：
1.单一职责：每个微服务只需要实现自己的业务逻辑就可以了，比如订单管理模块，它只需要处理订单的业务逻辑就可以了，其它的不必考虑
2.服务自治：每个微服务从开发、测试、运维等都是独立的，包括存储的数据库也都是独立的，自己就有一套完整的流程，我们完全可以把它当成一个项目来对待。不必依赖于其它模块。
3.轻量级通信：首先是通信的语言非常的轻量，第二，该通信方式需要是跨语言、跨平台的，之所以要跨平台、跨语言就是为了让每个微服务都有足够的独立性，可以不受技术的钳制。
4.接口明确：由于微服务之间可能存在着调用关系，为了尽量避免以后由于某个微服务的接口变化而导致其它微服务都做调整，在设计之初就要考虑到所有情况，让接口尽量做的更通用，更灵活，从而尽量避免其它模块也做调整。
使用：
服务拆分：
1.微服务拆分原则:领域模型、限定上下文、组织架构、康威定律
2.每个服务有自己的数据库
3.微服务之间确定服务边界,通过共享模型建立联系
数据一至性
1.使用最终一致性来代替强一致性
2.可靠性事件模式
3.补尝模式
服务通信
1.通信技术方案: RPC vs REST vs 异步消息
2.服务注册和发现
3.负载均衡
服务网关
1.API Gateway
2.划分前端服务的后端服务，移动端服务
3.身份认证、路由服务、限流防刷、日志统计
高可观察
1.健康检测、集中监控
2.日志聚合及检索
3.分布式追踪
可靠性
1.流量控制，超时控制
2.舱壁隔离，熔断机制
3.服务降级, 幂等重试
微服务是近期兴起的一种架构模式，因此再使用时，我们就会遇到不同的坑，比如需要依赖的中间件更新速度比较快，因此会造成每个版本在使用上的不同。因此在使用时请注意尽量选择一些大公司已经使用的技术。
在.Net Core中使用的技术
服务治理发现：Consul
熔断降级：Polly
网关： Ocelot
身份认证：Identity Server
RPC通信：Thirft
分布式配置中心：Apollo（阿波罗）
监控插件：App Metrics
分布式日志收集框架: Exceptionless
时间序列数据库:InfluxDB
开源仪表盘工具:Grafana
