微服务体系
什么是微服务？
什么是单体架构？
单体架构的问题？
1.复杂性高
1.1 代码难以理解，复用性低
1.2 难以理解导致代码质量低，复杂性进一步增加
1.3 代码难以被修改和重构
2.伸缩性差
2.1 单体只能按整体横向扩展，无法分模块垂直扩展
2.2 IO密集型模块和CPU密集型模块无法独立升级和扩容
3. 可靠性差
3.1 一个bug有可能引起整个应用的崩溃
4. 阻碍技术创新
4.1 受技术栈限制，团队成员使用同一框架和语言，模块得不到拆分，不能使用新的语言和框架
4.2 升级和变革技术框架变得困难，当有符合业务场景的新技术产生或者新版本时，升级和变革技术框架所带来的重构成本和风险很高
4.3 想尝试新的语言也变得很困难，因为开发成本的上升，重构和新需求迭代无法协调，所哟最终只能是妥协继续使用原来的框架和语言
什么是服务化？
服务化就是把传统的单机应用中的本地方法调用，改造成通过接口产生的远程方法调用
通过服务化，可以解决单体应用膨胀，团队开发耦合度高，协作效率低下的问题
微服务定义
服务拆分粒度更细
服务对立部署
服务对立维护
服务治理能力要求高
微服务的有点
易于开发与维护
独立部署
伸缩性强
与组织结构相匹配
技术异构型
微服务和Docker
服务拆分
什么时候应该拆分单体应用？
服务化拆分具体该如何实施呢？
服务拆分的两种方式：纵向拆分（业务），横向拆分（公共功能，发邮件，文件管理）
单体架构--微服务的问题
如何定义服务
如何发布和订阅服务
如何治理服务
如何定位
如何监控服务
服务治理
服务治理可以说是微服务架构中最为核心和基础的模块，它主要用来实现各个微服务实例的自动化注册与发现
在微服务架构中，过多的服务会出现的问题：
1. 需要配置N个服务的网络位置，加大配置的复杂性
2.服务的网络位置变化，都需要改变每个调用者的配置
3.集群的情况下，难以做负载
服务注册和发现
1. 在服务发现框架中，通常都会构建一个注册中心，服务提供者（就是提供服务的一方）按照一定格式的服务描述，向注册中心注册服务，声明自己能够提供哪些服务以及服务的地址是什么，完成服务发布
2. 服务消费者（就是调用服务的一方）请求注册中心，查询所需要调用服务的地址，然后以约定的通信协议向服务提供者发起请求，得到请求结果后再按照约定的协议解析结果
3.注册中心的工作流程是：
服务提供者启动：向注册中心注册自己提供的服务
消费者启动，向注册中心订阅自己需要的服务
注册中心返回服务提供者的列表给消费者
消费者从服务提供者列表中，按照负载均衡算法，选择一台发起请求
Consul 服务发现与配置