一、什么是微服务？
1、单体应用的痛点
部署效率低下
团队协作开发成本高
系统高可用性差
2、什么是服务化
把传统的单体应用中的本地方法调用，改造成通过RPC、HTTP产生的远程方法调用
把模块从单体应用中拆分出来，独立成一个服务部署
用户模块就可以独立开发、测试、上线和运维，可以交由专门的团队来做，与主模块不耦合
3、从单体到微服务架构
4、什么是微服务？
一种架构风格。
开发单个应用作为一系列小型服务的套件，其中每个服务都运行在自己的进程中，并且通过轻量级的机制实现彼此间的通信，这通常是HTTP资源API。
这些服务是围绕着业务功能构建的，并且可以通过完全自动化的部署机制进行独立部署。
这些服务的集中式管理做到了最小化（例如docker相关技术），每一种服务都可以通过不同的编程语言进行编写，并且可以使用不同的数据储存技术。
二、微服务的特点
组件以服务形式来提供
是产品不是项目
轻量级通信、独立进程
分散治理、去中心化治理
容错性设计
会带来组织架构的调整
三、微服务的优缺点
1、优点
服务简单、便于学习和上手，相对易于维护
独立部署，扩展灵活
技术栈丰富
2、缺点
运维成本过高
接口可能不匹配
代码可能重复
架构复杂度提高
3、单体应用、微服务复杂度和生产力之间的关系
四、微服务的两大门派（Spring Cloud和Dubbo）
Spring Cloud：众多子项目
dubbo：高性能、轻量级的开源Java RPC框架，它提供了三大核心能力：面向接口的远程方法调用，智能容错和负载均衡，以及服务自动注册和发现
dubbo提供的能力只是Spring Cloud的一部分子集
1、两大门派对比
2、通信协议对比
RPC vs REST
dubbo服务提供方与调用方接口依赖方式太强
dubbo服务对平台敏感，难以简单复用
3、文档质量
dubbo的文档在国内开源框架中算是一流，提供了中文与英文两种版本
Spring Cloud文档体量大，更多的是偏向整合，更深入的使用方法还是需要查看其整合组件的详细文档
五、微服务的拆分
1、什么时候进行服务的拆分？
第一阶段的主要目标是快速开发和验证想法
进一步增加更多的新特性来吸引更多的目标用户
同时进行开发的人员超过10人，这个时候就该考虑进行服务化拆分了
2、不适合拆分的情况
小团队，技术基础较薄弱
流量不高，压力小，业务变化也不大
对延迟很敏感的低延迟高并发系统
3、服务化拆分的两种姿势
纵向拆分（按业务模块拆分）
横向拆分（按功能拆分）
结合业务综合分析
六、微服务的扩展
x轴-水平复制
y轴-功能解耦
z轴-数据分区
自动按需扩展
根据CPU负载程度、特定时间（比如周末）、消息中间件的队列长度、业务具体规则、预测等来决定是否扩展
自动分配一个新的服务实例，提高可用性
提高了可伸缩性（比如双11之后，自动减少服务器）
具有最佳使用率，节约成本
七、微服务的重要模块
服务描述
注册中心
服务框架
负载均衡
熔断和降级
网关