微服务的诞生
影响企业“持续快速地响应市场需求的变化”的因素很多,但从企业应用系统架构的角度来讲,就需要一个能够面对变化的,甚至是主动拥抱变化的架构。
那么单体应用架构能不能满足企业应对变化的要求呢?
变更周期长:两天到一周的问题修复周期;两周到三周,甚至一两个月的需求变更周期;一个月到两个月的版本发布计划……也许在某些需求比较稳定,市场变化不明显的领域,这样的频率是可以接受的。但是在“你死我活”,竞争激烈的领域,如果只具备这样的响应力则注定是要被动挨打的。
那么是什么样的原因导致单体应用“快”不起来?
- 开发:所有代码都放在一起,大量紧耦合的代码导致应用模块间的界限日益模糊,改一处而动全身,有时程序员甚至无从下手,拖慢了修复问题和修改变更的速度;
- 测试:当频繁变更时,就需要做大量的回归测试,如果当测试过程中发现问题还要重新修改,延长了测试时间;
- 部署:所有功能都被打进一个发布包中,往往需要彼此等待大部分或所有模块开发,测试完成才能进行统一部署,拖长了发布时间……
- 单体应用就像代步用的马车,你可以增加马匹的数量来增强马车的运输能力,却永远受限于马的速度。这时我们需要一种可以真正提高速度的工具——一辆真正的汽车:微服务。
什么是微服务?
简单的说,微服务架构就是以业务域或业务功能为边界,将一个大而全的应用拆分为可以独立开发,独立部署,独立测试,独立运行的一组小的应用,并且使用轻量级通用的机制在这组应用间进行通信。
为什么微服务能够真正的“快”起来?
可以看出微服务的特点是小而独立,轻量级通讯。
- 正是因为小,所以每个微服务的逻辑相对简单,代码量也小很多,进而修复问题及修改变更会快很多;
- 因为独立,每个微服务都可以单独进行修改,测试,部署,而多个微服务可以并行演进,从而可以缩短测试,部署和发布的时间;
- 同样是因为独立,每个微服务都可以根据实际情况,单独的横向拓展;
- 因为轻量级通讯,每个微服务才可以独立起来,贯彻高内聚低耦合的架构思想……
这些听起来似乎有些似曾相识,难道SOA不也是这样承诺的吗?
官方点的描述:
微服务是一种架构风格,一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署,各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下,每个任务代表着一个小的业务能力。
可以在“自己的程序”中运行,并通过“轻量级设备与HTTP型API进行沟通”。关键在于该服务可以在自己的程序中运行。通过这一点我们就可以将服务公开与微服务架构(在现有系统中分布一个API)区分开来。在服务公开中,许多服务都可以被内部独立进程所限制。如果其中任何一个服务需要增加某种功能,那么就必须缩小进程范围。在微服务架构中,只需要在特定的某种服务中增加所需功能,而不影响整体进程。
微服务的“前世”——SOA
时至今日SOA通常被看作是企业IT中的一个失败的运动,对于许多投资它的人来说,创伤仍然是新鲜的。那么微服务与SOA到底有哪些不同,为什么SOA失败了,但是微服务却大规模的流行了起来?
1. SOA没有大规模的,经过验证的,标准的落地实践,更多的是停留在理论层。同时很多SOA产品提供商也曲解了SOA的理念,以便更靠近自己的产品,使其大卖。而微服务的兴起却是依赖于大规模生产环境的考验,是实实在在可落地的,这增强了使用者的信心。比如Spring Cloud框架,是由Netflix公司进行开源,并且由Pivotal进行封装的微服务框架,经过了长时间的生产环境的验证;
2. 缺乏成熟工具支撑。 现时的IT环境已经发生巨变。正是由于敏捷开发管理,容器及容器云技术,DevOps等等方法,实践,工具,平台的不断成熟,微服务才可以如此迅速的发展起来。敏捷开发管理提供了一种应对需求快速变化的软件开发方法,顺带减少了交付过程中的一些浪费,容器及容器云技术解决了基础设施快速到位的问题,DevOps解决了持续集成,持续部署的问题。而微服务则是从应用架构角度解决了应用快速适应变化,高容错,横向拓展等问题。这四者互为补充,构建了一套完整的能够快速响应变化的IT整体环境。反观SOA的时代,没有“群雄”的支持,SOA也是想法虽好,却独力难支。
微服务的“今生”
以Spring Cloud为代表的微服务框架正在如火如荼的在企业IT架构中活跃着,而以Istio为代表的Service Mesh微服务架构正在悄然兴起。Service Mesh以更为合理的架构设计和更为简单使用方法吸引了众多的追随者。但是目前Service Mesh产品还没有大规模在生产环境上使用的案例,比如Istio也只发布了0.8版本,WeiBo Mesh,华为Mesher,蚂蚁金服的SOFA Mesh也都处于研发阶段等等。总的来说,Service Mesh前景美丽,但道路曲折。