控制复杂性。由于业务的复杂性,需要我们用更好的手段帮助研发组织克服认知障碍,更好的分工协作。分而治之,关注点分离等手段皆是如此。
应对不确定性。业务在快速发展,需求在不断变化。即使再完美的软件架构,然而随着时间的推移,团队的变化,软件架构的调整不可避免。读《设计模式》,《微服务设计》等书字里行间写的都是“解耦”两字,让我们关注架构中确定性和不确定性的分离,提升架构的稳定性和应变能力。
管理系统性风险。管理系统中的确定性以及不确定性风险,规避已知陷阱,对未知的风险做好准备。
侵入性:服务治理本质是横向的系统级关注,是与业务逻辑正交的。但在现有微服务框架中,其实现方式和生命周期与业务逻辑耦合在一起的。服务治理能力的增强需要微服务框架的升级,会导致整个系统所有组件的重新构建和部署,导致升级和维护成本提升。
实现绑定:由于微服务框架代码库通常由特定语言实现,难以支持多语言(polyglot)实现。随着业务的快速发展,异构系统之间的集成逐渐成为挑战。
体积更小 - 对于微服务分布式架构而言,更小的体积意味着更少的下载带宽,更快的分发下载速度。
启动速度更快 - 对于传统单体应用,启动速度与运行效率相比不是一个关键的指标。原因是,这些应用重启和发布频率相对较低。然而对于需要快速迭代、水平扩展的微服务应用而言,更快的的启动速度就意味着更高的交付效率,和更加快速的回滚,以及更快的故障恢复速度。
占用资源更少 - 运行时更低的资源占用,意味着更高的部署密度和更低的计算成本。