小明:

现在开发一个 DSF，怎么能即符合公司的宗旨，又能做到微服务的概念?

苏格拉底:

服务的划分?

怎么舒服怎么来!

虽然他说是微服务, 只代表他支持微服务, 不代表你不能胡搞瞎搞

如果你全写在一个里面, 发现比拆开来写更方便, 那你就全写在一个服务里面.

小明:

全写在一个里面, 和之前没有区别, 那么就变成了单体应用了, 不是说单体应用是不好的吗?

苏格拉底:

单体应用一定是坏的嘛? 并不一定

还是要结合具体场景

什么时候你觉得该拆了

把单体应用中可以独立功能的, 属于一个事务的, 搞出来改成微服务

微服务强调的是变现速度, 如果你没有足够的经验却全改成微服务, 那么反而会增本降效,

小明:

我知道了, 要按照自己的实际需求来设计微服务的粒度.

苏格拉底:

是的, 比如, 分开写多个服务，服务器申请, 部署和运维就头疼了

微服务并非没有代价

划分了微服务之后, 监控, 运维, 调试都变得更加困难

小明:

那我们为什么还要用微服务? 微服务有什么好处?

苏格拉底:

那么微服务带来了什么好处?

合理的划分微服务, 可以达到屏蔽异构, 支持不同的语言实现, 不同的后端, 选用合适的语言和存储进行成本和收益的权衡.

通过将单体应用解耦, 实现职责的分离, 可以小步快跑,支撑更快速的迭代.

重要的是解耦

解耦良好的 SOA, 就可以称之为微服务

如果解耦良好, 当你觉得需要拆分成一个个单独的微服务以提高迭代速度, 那么也是分分钟的事情.

小明:

我明白了, 微服务强调的是解耦, 这和软件设计的古老理念: 高内聚, 低耦合 是一贯相承的,

微服务并不是一个新造的概念突然火了. 我们在实践中, 应该根据自身需求, 合理的划分微服务.

才能达到降本增效的目的.

苏格拉底:

你说的对.

苏格拉底:

车坊 CBD 有一家酸菜鱼特别好吃, 一起去吧