一、微服务架构的特点：
1.将系统服务完全独立出来，并将服务层抽取为一个一个的微服务；
2.采用一些轻量级协议进行传输；
3.服务拆分力度更细，有利于资源重复利用，提高开发效率；
4.可以更加精准的制定每个服务的优化方案，提高系统可维护性
5.相比ESB更轻量；
微服务(抽象)<==>单体应用
模块单体？数据库单体？==》服务对应单体模块，单体数据库？？
例如：
用户服务对应用户服务数据库
订单服务对应订单数据库.......
- 所有数据库相互隔离，由各自的服务自己负责
- 微服务架构使整个系统的分工更加明确，责任更加清晰，每个人只专心负责为其他人提供更好的服务
什么是单体架构
- 就是将应用程序的所有功能都放在一个项目或解决方案中，不管有没有分布式，它们的代码都运行在同一个进程中，所有的应用资源也都在同一个进程中
- 适用于简单微小的应用
单体架构应用问题
- 复杂性高——代码难以理解、难以理解导致代码质量低，复杂性进一步增加、代码难以被修改和重构
- 伸缩性差——单体只能按整体横向扩展，无法或很难分模块垂直扩展；IO密集型模块和CPU密集型模块无法独立升级和扩容；
- 可靠性差——一个bug可能导致整个应用崩溃
- 阻碍技术创新——
- 受技术限制，团队成员使用同一框架和语言，模块得不到拆分，不能使用新的语言和框架；
- 升级和变革技术框架困难，当有符合业务场景的新技术产生或新版本时，升级和变革技术框架所带来的重构成本和风险很高
- 想尝试新的语言也变得很困难，因为开发成本的上升，重构和新需求迭代无法协调，导致最终只能是妥协继续使用原来的框架和语言
注：单体项目，适用于简单固定业务的项目，对于无法固定业务的不适用于单体业务。
微服务定义
- 什么是服务化
- 服务化就是把传统的单机应用红的本地方法调用，通过改造，改造成通过接口产生的远程方法调用
- 通过服务化，可以解决单体应用膨胀、团队开发耦合度高、协作效率低下的问题
- 服务拆分粒度更细
- 服务独立部署
- 服务独立维护
- 服务治理能力要求高
架构参考如下(仅供参考了解)：网关、注册中心
微服务的优点：拆分
- 易于开发与维护
- 独立部署
- 伸缩性强
- 与组织结构相匹配
- 技术异构性——不同的服务，可使用不同的技术，同时使用多种开发语言或多种数据库
总结：微服务架构是将复杂臃肿的单体应用进行细粒度的服务化拆分，每个拆分出来的服务各自独立打包部署，并由不同的团队开发和运维，从而极大
提高了应用交付的效率，并被各互联网公司所普遍采用。
微服务和Docker
服务拆分
什么时候应该拆分单体应用？
服务化拆分具体如何实施？
服务拆分的方式：纵向拆分、横向拆分——拆分方式多种，不能一概而论
ConSul
ConSul是HashiCorp公司推出的使用Go语言开发的开源工具，用于实现分布式系统的服务发现与配置
ConSul是分布式的、高可用的、可横向扩展的
ConSul提供了服务发现、健康检测、Key/Value存储、多数据中心等功能
下载地址：https://www.consul.io/
K8S
Docker基础上编排、调度；集群管理；弹性伸缩；服务治理；负载均衡；监控；认证...
Docker：静态容器，可多个，类似--类对象可多个
Service Fabric--微软开源
.net core下的微服务构件
- 服务治理：Consul
- API网关：Ocelot
- 作业调度：Quartz.NET,Hangfire
- 分布式日志：Exceptionless
- ESB：Masstransit（RabbitMQ）
- APM：Metrac.App,Buttfly
- ......