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