微服务
服务(service)一定要区别于系统,服务一个或者一组相对较小且独立的功能单元,是用户可以感知最小功能集。
广义上,微服务是一种分布式系统解决方案,推动细粒度服务的使用,这些服务协同工作。
微服务架构是将复杂的系统使用组件化的方式进行拆分,并使用轻量级通讯方式进行整合的一种设计方法。可以用“分而治之,合而用之”来描述。
微服务是通过这种架构设计方法拆分出来的一个独立的组件化的小应用。
微服务架构和整体式架构的区别
单体式架构的缺陷
- 复杂性逐渐变高
- 技术债务逐渐上升
- 维护成本大
- 持续交付周期长
- 技术选型成本高
- 可扩展性差
微服务架构的特性
-
单一职责
-
轻量级通信
通常指语言无关,平台无关
-
进程隔离
微服务架构的缺点
- 运维要求较高
- 分布式的复杂性
- 接口调用成本高
- 重复劳动
对比表格
传统单体架构 | 分布式微服务化架构 | |
---|---|---|
新功能开发 | 需要时间 | 容易开发和实现 |
部署 | 不经常而且容易部署 | 经常发布,部署复杂 |
隔离性 | 故障影响范围大 | 故障影响范围小 |
架构设计 | 初期技术选型难度大 | 设计逻辑难度大 |
系统性能 | 相对时间快,吞吐量小 | 相对时间慢,吞吐量大 |
系统运维 | 运维难度简单 | 运维难度复杂 |
新人上手 | 学习曲线大(应用逻辑) | 学习曲线大(架构逻辑) |
技术 | 技术单一而且封闭 | 技术多样而且容易开发 |
测试和差错 | 简单 | 复杂(每个服务都要进行单独测试,还需要集群测试) |
系统扩展性 | 扩展性差 | 扩展性好 |
系统管理 | 重点在于开发成本 | 重点在于服务治理和调度 |
为什么要用微服务架构
- 开发简单
- 快速响应需求的变化
- 随时随地更新
- 系统更加稳定可靠