赞
踩
1 服务粒度:整体上来说,SOA 的服务粒度要粗一些,而微服务的服务粒度要细一些。
2 服务通信:
SOA 采用了 ESB 作为服务间通信的关键组件,负责服务定义、服务路由、消息转换、消息传递,总体上是重量级的实现;
微服务推荐使用统一的协议和格式,例如,RESTful 协议、RPC 协议,无须 ESB 这样的重量级实现,且仅仅做消息传递,对消息格式和内容一无所知。3 服务交付:
SOA 对服务的交付并没有特殊要求,因为 SOA 更多考虑的是兼容已有的系统;
微服务的架构理念要求“快速交付”,相应地要求采取自动化测试、持续集成、自动化部署等敏捷开发相关的最佳实践。4 应用场景:
SOA 更加适合于庞大、复杂、异构的企业级系统;
微服务更加适合于快速、轻量级、基于 Web 的互联网系统,这类系统业务变化快,需要快速尝试、快速交付。
SOA 和微服务本质上是两种不同的架构设计理念,只是在“服务”这个点上有交集而已
微服务并没有减少复杂度,而只是将复杂度从 ESB 转移到了基础设施
1 如果服务划分过细,则服务间关系会很复杂
2 如果服务数量太多,团队的开发效率会急剧下降
3 如果调用链太长,导致性能下降、问题定位困难
4 如果没有自动化支撑,则无法快速交付
5 如果没有服务治理(服务路由、服务故障隔离、服务注册和发现等,需要依赖自动化的服务管理系统),微服务数量多了后管理混乱
基于团队规模进行拆分:
微服务设计和开发阶段,一个微服务三个人负责开发;
维护阶段,平均 1 个人维护 1 个微服务甚至几个微服务都可以,考虑到人员备份问题,则每个微服务最好都安排 2 个人维护,每个人都可以维护多个微服务。
根据团队规模划分业务模块的粒度
将系统中的业务模块按照稳定性排序,将已经成熟和改动不大的服务拆分为稳定服务,将经常变化和迭代的服务拆分为变动服务。
稳定的服务粒度可以粗一些,即使逻辑上没有强关联的服务&
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。