微服务基本概念
专注做好一件事. 一方面服务的大小是相对的, 而且服务越小, 服务数量越多, 管理起来就越复杂, 这也需要利弊权衡.
自治性. 即服务通过暴露 API, 服务间通过 API 通信, 解耦合.
微服务的好处
微服务的好处主要是针对传统的大型复杂服务而言
技术异构性. 每个服务可以选用自己的技术, 尝试自己需要的, 或者新的技术, 而不影响其他服务
弹性. 服务之间有边界, 即一个服务有问题不会影响其他功能, 或者其他服务负责的功能.
扩展. 如过一个服务有性能问题需要扩展, 那么不需要同时扩展其他服务.
简化部署. 一个服务的代码修改, 不需要部署其他服务.
与组织结构相匹配. 各个团队可以负责自己的 N 个服务, 而不用管其他团队的服务.
可组合性. 因为通过 API 进行服务通信, 所以其他模块都可通过 API 对接某个服务
问题: 没有银弹. 多服务管理复杂, 部署, 测试, 监控等方面都需要额外的开销.
如何建模微服务
主要讲了什么时候划分出微服务, 总结是, 先内部分模块解决, 再等界限清晰, 最后划分微服务
模块和服务, 不要过早使用微服务: 微服务是目标做到, 而且容易做到 高内聚低耦合的, 当我们通过逻辑或者功能来划分时, 比如一个进程内, 可以优先考虑多模块划分, 这也是一种减少耦合的方式. 而这些模块的划分, 也是以后划分微服务的最好备选.
所以一个新系统, 如果界限不是特别清晰, 可以先考虑做模块划分, 因为服务之间的边界搞错了后面的修复代价很大. 所以最好等成熟后, 界限稳定后, 再划分新的微服务.
集成
集成是微服务相关技术中最重要的一个. 也能很好的保持微服务自治性.
这些技术能够提供的好处显而易见, 服务隐藏了内部实现细节, 内部的技术细节, 对外只暴露 API, 服务的内部修改也不影响外部的访问.
避免使用共享数据库
服务之间通过 API 相互访问, 如果通过共享数据库, 就会把数据库全都暴露出来, 所有细节外部都能看到, 而通过 API 的合理约束, 数据库的很多实现就会被屏蔽, 内聚性能得到很好的保证.
HTTP 和 RPC
HTTP 请求一般都通过 JSON, 这样请求的封装开销是个问题, 明文传输更易于调试, 而且现在流行程度也决定了它的适用性
RPC 延时更低, 很多都是二进制协议更高效,
异步协作
微服务的时间发布和消费需要考虑异步, 消息队列 (Rabbit MQ 等) 是常见的选择, 优势是 可订阅可消费, 消息也有状态, 不会重复消费, 降低耦合, 伸缩性好, 劣势是使用有复杂度. 不过已经是最优解
服务即状态机
合理的服务要有自己的状态, 比如服务有自己的配置 db, 每次操作服务就会更新 db 的值(状态), 避免服务成为贫血服务(即只做 CRUD 的简单服务)
版本管理
经常遇见的一个情况, 是新用户有新需求, 那么可以做的选择是
- 同一个服务上做新的接口给新用户, 老的接口给老用户, 最后实现老用户迁移, 最终停止使用老接口
- 同时使用多个版本的服务, 每个服务独立对外提供接口
大部分情况下, 还是第一种方案最适合, 第二种方案过重. 短时间使用两个服务也许是合理的, 但是这样多个接口存在的时间越长, 就越应该考虑第一种方案,
来源: http://www.bubuko.com/infodetail-2967890.html