微服务基础

单体应用的痛点

• 部署效率低下
• 团队协作开发成本高
• 系统高可用性差

服务化

1. 把传统得到单机应用的本地方法调用，改造成RPC、HTTP产生的远程方法调用
2. 把模块从单体应用中拆分出来，独立成一个服务部署
3. 用户模块就可以独立开发、测试、上线和运维，可以交由专门的团队来做，与主模块不耦合

什么是微服务

1. 一种架构风格
2. 开发单个应用作为一系列小型服务的套件，其中每个服务都运行在自己的进程中，并通过轻量级的机制实现彼此间的通信，这通常是HTTP资源API
3. 这些服务是围绕着业务功能构建的，并且可以通过完全自动化部署机制进行独立部署
4. 这些服务的集中式管理做到了最小化，每一种服务都可以通过不同的编程语言进行编写，并且可以使用不同的数据存储技术

微服务的特点

1. 组件以服务形式来提供
2. 一个产品不是一个项目
3. 轻量级通信、独立进程
4. 分散治理、去中心化治理
5. 容错性设计
6. 会带来组织架构的调整

微服务的优缺点

• 服务简单、便于学习和上手、相对易于维护
• 独立部署，灵活扩展
• 技术栈丰富

微服务缺点

1. 运维成本过高
2. 接口可能不匹配
3. 代码可能重复
4. 架构复杂度提高

微服务两大门派

• Spring Cloud：众多子项目
• dubbo：高性能、轻量级的开源Java RPC框架，提供三大核心能力：面向接口的远程方法调用，智能容错和负载均衡，以及服务自动注册和发现

dubbo提供的能力只是Spring Cloud的一个子集

 通信协议对比

RPC vs REST

dubbo服务提供方与调用方接口依赖方式太强，Spring Cloud不是强依赖的

dubbo服务队平台敏感，难以简单复用，需要集成其他系统需要代理，Spring Cloud本身就是REST

微服务拆分

考虑拆分的时机

• 第一阶段的主要目标时快速开发和验证想法
• 进一步增加更多的新特性来吸引更多的目标用户
• 同时进行开发的人员超过10人，这个时候就该考虑进行服务化的拆分了

不适合拆分的情况

• 小团队，技术基础较薄弱
• 流量不高，压力小，业务变化也不大
•  对延迟很敏感的低延迟高并发系统

微服务拆分的两种姿势

1. 纵向拆分，按独立性拆分
2. 横向拆分，按重复的部分拆分
3. 结合业务综合分析

服务扩展

x轴-水平复制：增加应用实例

y轴-功能解耦：拆分业务

z轴-数据分区：根据用户数据拆分数据库

自动按需扩展

根据资源负载、时间等策略预测和扩展

自动分配一个新的服务实例，提高可用性

提高了可伸缩性，高峰过后自动减少服务器

具有最佳使用率，节约成本

微服务重要模块

• 服务描述
• 注册中心
• 服务框架
• 负载均衡
• 熔断和降级
• 网关