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