微服务是当前互联网产品的一个技术架构趋势,近两年伴随着Docker容器计算的发展和普及,微服务架构在业界逐渐落地,那么驱动企业进行微服务化架构改造的根本推动力是什么?如何在企业内部实施微服务架构?实施微服务契构需要哪些技术框架和基础设施?这些都是企业技术人员需要了解并关心的问题,也是要具体讨论的问题。

微服务作为对应单体应用出现的概念,其架构通常有哪些优势呢?

  • 项目工程简洁。一个复杂的产品功能集合,代码仓库规模往往随着业务复杂度的增加而线性增加。对于单体应用来说,代码的堆积意味着工程规模的迅速膨胀。而对于微服务来说,因为每个微服务承担的职责小而且单一,所以工程规模简洁可控。

  • 升级代价小。当一个产品所有的功能都集中在同一个应用时,对程序的升级会带来两方面的影响:一是项目工程过大造成的应用启动时间过久,我们见过有些产品一个应用实例的启动时间需要半个小时以上,这对业务来说显然不可行。二是每次hotfix都需要对整个应用重启,引起业务的不稳定,而微服务架构恰恰相反,每个服务独立升级,对业务整体的影响极小。

  • 扩展性好。对于互联网产品来说,产品迭代速度很重要。对于一个庞大的单体应用来说,牵一发而动全身,无论对产品功能的扩展性还是性能的扩展性来说,都是一个很大的挑战。通过微服务化,把业务中扩展性差的部分独立出去,不同的业务类型采用不同扩展方案,可以提升业务整体的可扩展性。

  • 稳定性好。单体应用的稳定性差主要体现在功能间的隔离性,对于单体应用而言,所有的功能都在同一个进程空间里,这意味着任何一个功能的bug可能会造成应用整个崩溃。微服务的好处是可以实现进程级别的隔离,单个服务异常很少会造成全局故障。

  • 人员变更影响小。项目中人员更迭并不少见,单体应用的交接要求被交接人员必须对整个项目非常熟悉,才有可能消化变更人员带来的负面影响,否则人员离职或转岗会影响项目的正常进度。实施微服务架构的团队往往同时也遵循“2 pizza”原则的组织架构,团队小而精,人员变更影响小。

  • 技术栈丰富。单体应用因为都跑在同一个进程里,所以项目的整体技术栈就被这个进程锁死了,比如说一个Java单体应用,无论业界的其他编程语言和开发框架如何发展,我们也无法利用起来,无法实现技术反哺业务。而微服务可以采用一些通用的服务间通信方式(HTTP等)去集成,使得服务的实现方式不局限于某个技术栈,适合用最合适的技术实现功能。

  • 开发效率高。主要体现在为服务架构下项目的学习曲线平滑,因为工程规模小,所以开发人员能很快做到对项目有一个大而全的认识。