 一提到Microservice微服务，你首先会联想到什么？简易的开发和部署，应用组件的独立可扩展性，避免长期技术锁定……这些都是微服务的优势。以云计算、互联网+、移动应用等为代表的新兴业务对IT运行效率、开发效率、业务模式创新等提出了更高的要求。有人说，传统行业对IT效率的变革需求是微服务成长的土壤，微服务正在成为许多企业构建应用时的首选。 什么是微服务？微服务如何落地？微服务的未来在哪里？让我们慢慢一步步梳理微服务的来龙去脉。 松耦合、自主化的微服务架构 随着云计算、Docker(容器)技术的发展，IT架构在不断演进，传统的单体应用架构已经无法满足业务敏捷性的需求。由于应用规模日益庞大，架构需要降低耦合度，同时提高运维效率和降低成本，此外还要避免因局部故障可能对整体业务可用性造成的影响。 微服务的概念诞生于2012年。作为加快Web和移动应用程序开发进程的一种方法，从2014年开始受到各方关注。本质上讲，微服务将单体应用模块功能进行拆分，每个微服务单独开发部署和运维，可以有效提升开发运维效率，保障整体可用性，实现持续集成与交付。 微服务是一种架构风格。一个大型复杂软件应用由一个或多个微服务组成，系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。 微服务架构是一种创建松散耦合且自主化服务的新型架构风格。从业界的实践来看，微服务核心技术架构主要包括以下几个方面：进程间通信、服务注册/服务发现、负载均衡、配置管理、熔断器、API网关。以微服务架构的兴起为标志，DevOps、平台即服务 (PaaS)、容器和持续集成与交付 (CI/CD) 方法，正在帮助企业超越面向服务的架构 (SOA) 等传统方式，实现更大规模的模块化系统创建和管理。 SOA 的好处是可以创建具有弹性的分布式应用，有效消除各类复杂的中央组件。然而，SOA与组织结构高度耦合，该架构能否获得成功在很大程度上依赖于重新规划后的组织结构，以及设计该架构的团队能力。有人认为，SOA创建的并非是兼具松散耦合和自主化特点的系统，而是一个需要复杂基础架构的相对脆弱的系统。而且，早期的SOA实施会造成供应商锁定，因为专有中间件往往只专注于集中化逻辑与持久化治理。 相反，微服务架构则在构建应用的每个步骤(从开发、部署到运营)中兑现了 SOA 的最初承诺，专注于简化技术，利用精简化的组件构建复杂系统。该架构通过基于异步HTTP或消息传递协议的简单、标准化的管道通信，取代集中化逻辑和集成基础架构(基于重量级、非标准化的平台)。SOAP、XML 和其他重量级协议和数据格式将被轻量级 JSON所取代。每项微服务都有自己的数据存储，不需要集中化管理和持久化。 当前主要的开源微服务框架包括Spring Cloud、Dubbo、gRPC等。我们以Spring Cloud为例来展开介绍。Spring Cloud是基于SpringBoot的一整套实现微服务的框架。它提供了微服务开发所需的配置管理、服务发现、断路器、智能路由、微代理、控制总线、全局锁、决策竞选、分布式会话和集群状态管理等组件。更重要的是，Spring Cloud与Spring Boot框架一起使用，会让用户更方便地开发基于微服务架构的云服务。SpringBoot旨在简化创建产品级的Spring应用和服务，简化配置文件，使用嵌入式Web服务器，含有诸多开箱即用的微服务功能。 Spring Cloud目前在Java微服务领域具有统治地位，而且有强大的社区支持。近两年，随着组件生态的进一步完善和生产案例的增加，Spring Cloud大有成为Java微服务框架的事实标准的趋势。 但是作为一项开源技术，Spring Cloud得到大量开发者追捧的同时，也有自身的一些问题需要使用者去解决。比如，部分周边组件功能不完善。Spring Cloud的开发支持界面十分友好，开发人员接受度非常高，但是Spring Cloud的配置管理、服务治理、应用发布等环节并不完善，需要通过周边工具完善。 国内PaaS厂商时速云在微服务治理方面早早做好了布局，研发出具有 Spring Cloud、 APM、 CSB、 Service Mesh 等主要能力的微服务 治理平台，支持独立部署在宿主机 系统， 或更加方便地通过时速云 PaaS 平台进行部署和管理。时速云对 Spring Cloud 的核心组件进行了深度定制和扩展， 包括 Eureka、 Zuul、 ConfigServer、 Hys-trix、 Zipkin、 AuthServer 等。 国内PaaS厂商MoPaaS认为，微服务架构就是将一个完整的应用从数据存储开始，垂直拆分成多个不同的服务，每个服务都能独立部署、独立维护、独立扩展，服务与服务间通过诸如RESTful API的方式互相调用。MoPaaS基于Spring Boot和Spring Cloud实现微服务架构，并且各个模块都是完全开源的。MoPaaS平台提供注册中心、配置中心、消息服务等组件可选，从而创建、编辑微服务;提供服务治理相关功能，包括服务查询、对于服务状态的展示、以拓扑图直观的展示微服务之间调用链、响应时间关系等;支持启用、禁用、分组等微服务管理功能;可以提供微服务的监控、告警等功能，包括节点CPU、内存等Metrics监控与告警，以及各节点上的服务监控与告警等。 企业如何过渡到微服务架构 目前，一些制造企业，主要是汽车制造、大型装备制造、航空业，以及金融行业的企业已经在初步尝试采用微服务架构。 企业如果要向微服务架构转变过渡，应该如何做呢? 在AWS中国区的网站上提供了关于微服务应用的教程，其中一个例子是，使用微服务作为用户应用程序负载均衡器的目标。用户可以使用微服务架构来构造应用程序，作为可以独立开发和部署的服务。具体来说，用户可以在各EC2实例上安装一个或多个这样的服务，每个服务在不同端口上接受连接。用户可以使用单个应用程序负载均衡器将请求路由到应用程序的所有服务。用户将EC2实例注册到目标组时，可以多次注册。对于每个服务，可使用该服务的端口注册实例。 而红帽公司认为，若想成功采用微服务架构，企业或组织就必须首先为其单体式架构创建一个稳固的基础，然后必须考虑和建立模块化、域边界和基本分布式系统理论，以发挥微服务的全部优势。此外，微服务还能为较复杂的系统创造更多优势，比如DevOps、PaaS、容器、服务复制和注册、主动监控和警告等。 企业是否已经为采用微服务做好了准备?红帽公司建议，企业可以从以下几个方面进行自查：是否构建了结构良好的单体式应用，是否明确了将微服务用于满足哪些特定需求，是否围绕微服务架构重新调整了团队结构，是否采用了最佳DevOps和CI/CD实践方法，是否明确界定了应用的业务范围，是否已经实施了微服务编排和管理工具与流程等。 部署微服务，既需要协调一致、技能精湛的团队，还需要高效的管理工具。构建一支采用扁平化组织结构，具备灵活性、多功能和自主化的高效团队是成功应用微服务的关键。 构建高效率、高技能的团队需要围绕业务功能，而非企业架构来重新协调人员配置。例如，Amazon的“两张披萨团队”原则，每组团队由8到10人组成，负责创建和维护其服务。此外，“康威定律”还指出，企业只能创造出与其组织结构相仿的设计。例如，如果对一个团队按照开发、运营、质保和安全几个部分进行划分，则会对团队的业务灵活性造成一定的限制，并可能导致进度延误。因此，企业在过渡到微服务之前，应先创立DevOps实践，预先明确其通信策略，从而有效缓解或防范上述问题的发生，避免创建失败的SOA或非高效的微服务架构。 2007年，红帽公司曾针对客户进行过一项有关微服务应用的调查，发现当前微服务主要被用来重新架构现有的应用程序，而行业更喜欢多运行、多技术、多框架的微服务。用户普遍接受的微服务的六大益处可以概括为：持续集成(CI)/持续部署(CD)、敏捷性、更高的可伸缩性、更快的交付时间、更高的生产效率、更容易调试和维护。但同时也必须注意落地微服务可能面对的严峻挑战，包括企业文化和组织结构上的挑战、微服务管理、诊断和监控、时间和资源管理。 红帽公司认为，微服务架构可以为企业带来诸多优势，例如各种应用组件的独立可扩展性，以及更快捷、更简便的软件开发与维护。但是，微服务可能无法为所有团队或项目带来同等的优势。过渡到微服务是一个循序渐进的过程，仅重构部分现有应用(而非全面过渡)是切实可行的做法。为成功采用微服务架构，企业必须首先根据现有平台标准构建和设计合理的应用，然后根据需要将应用重构为微服务集合，以满足业务需求，同时还要配以适当的人员、流程和工具。 一句话，微服务将促进更快的开发和部署，并让企业摆脱长期的技术锁定，从而获得业务发展和产品选择的自由。 微服务的挑战与未来 灵雀云认为，传统开发将面临更加严峻的挑战。 第一，研发成本高，主要体现在以下几方面。代码重复率高。在实际项目分工时，开发都是各自负责几个功能，即便开发之间存在功能重叠，往往也会选择自己实现，而不是类库共享。主要原因是从技术架构角度看，传统垂直架构的特点是本地API接口调用，不存在业务的拆分和互相调用，使用到什么功能就本地开发，非常方便，不需要过度依赖于其它功能模块。从考核角度来看，共享很难推行，只需要对自己开发的模块交付质量负责，没有义务为他人提供并维护公共类库，这个非常耗费成本。跨地域、跨开发小组协调很困难，业务团队可能跨地域研发，内部通常也会分成多个开发小组，各开发小组之间的协调和沟通成本非常高。需求变更困难。代码重复率变高之后，已有功能变更或者新需求加入都会非常困难。以充值缴费功能为例，不同的充值渠道开发了相同的限额保护功能，当限额保护功能发生变更之后，所有重复开发的限额保护功能都需要重新修改和测试，很容易出现修改不一致或者被遗漏，导致部分渠道充值功能正常，部分存在Bug的问题。 第二，运维效率低。在传统的MVC架构中，业务流程是由一长串本地接口或者方法调用串联起来的，臃肿而冗长，而且往往由一个人负责开发和维护。随着业务的发展和需求变化，本地代码在不断的迭代和变更，最后形成了一个个垂直的功能孤岛，只有原来的开发者才理解接口调用关系和功能需求，一旦原有的开发者离职或者调到其他项目组，这些功能模块的运维就会变得非常困难。当垂直应用越来越多时，连架构师都无法描述应用间的架构关系，随着业务的发展和功能膨胀，这种架构很容易发生“腐化”：测试、部署成本高，业务运行在一个进程中，因此系统中任何程序的改变，都需要对整个系统重新测试并部署;可伸缩性差，水平扩展只能基于整个系统进行扩展，无法针对某一个功能模块按需扩展;可靠性差，某个应用BUG，例如死循环、OOM等，会导致整个进程宕机。 对于微服务的未来，UMCloud认为，意识重于技术。康威法则给我们的启示：软件系统的接口结构会映射组织的沟通结构，如果组织架构不合理，就无法建立一个高效的系统架构。一般在系统架构调整时，要提前考虑相应的组织架构的调整，两边联动才能产生效果。康威法则是近年流行的微服务架构背后的组织原理。 Adrian Cockcorft是Netflix前云架构师，在经历Netflix大规模微服务架构的成功实践后，他提议现代组织要打破谷仓式职能壁垒，拥抱基于微服务的跨职能产品团队组织模式。 目前大部分研发组织仍严格划分职能，职能间交集少，标准的研发流程以产品经理和研发团队 (包括用户体验团队) 反复多次讨论新功能需求开始，研发团队再将新功能用代码实现，然后代码被提交质量保证团队进行测试。这中间又涉及双方的多次会议交互。测试通过后提交DBA和运维上线，这中间又涉及和DBA、系统、网络和存储管理员的多次交互 (一般通过工单系统)，整个流程缓慢。 康威法则告诉我们，软件系统的接口结构会反映组织的社交结构。所以如果组织要真正转型到微服务架构，就必须围绕微服务产品组织团队，基于DevOps 模式开展工作。组织内不再以流水线方式设置产品经理、用户体验经理、研发经理等独立职能角色。每个核心产品 (实现为微服务) 有一个经理，即负责管理和监督团队，也负责微服务软件研发和交付的各个环节，从概念到发布。组织内不再有独立的运维团队和职能细分，只有负责基础设施产品 (IaaS/PaaS) 的平台团队，提供自动化和自助式平台 UI Portal或API，支持各个产品团队持续交付微服务。 UMCloud在容器云和微服务上的实践表明，要在企业内部实施微服务架构，更多的是思维上的转变。对于微服务架构：技术上不是问题，意识比工具重要。 一般提到微服务都离不开DevOps和Docker，理解微服务架构是核心，DevOps和Docker则是工具和手段。UMCloud认为，未来服务网格将会促进微服务的大规模落地。如果我们能够以透明化方式在服务与网络之间插入一个基础设施层，借此为运营人员提供必要的控制能力，同时帮助开发人员不必在其代码当中引入分布式系统带来的专用解决方案，那么很多挑战将迎刃而解。正如微服务架构能够帮助各功能团队实现彼此解耦一样，服务网格能够帮助运营人员从应用程序功能开发与发布流程当中“解耦”出来。Istio 项目即因此而生，它能够以系统化方式将代理机制接入至网络路径当中，从而将不同微服务转化为综合性服务网格。Istio项目提供了一种统一的方法配置多种必要的功能，使得运营人员能够更加轻松地运作高弹性水平服务网格。开发者在设计Istio项目时，应充分考虑到网络内所运行的各服务的透明性，允许团队随着时间推移逐步采用Istio提供的各项功能。 微服务带来的复杂度也让很多企业头疼，尤其是服务间通信。用户对保证服务间通信的端到端性能和可靠性的需求，催生了下一代微服务Service Mesh。从2017年开始，Service Mesh渐渐为业内人士所熟知。作为服务间的通信层，Service Mesh可以提供更加安全、快速、可靠的服务间通信。被誉为下一代微服务的Service Mesh可能迎来爆发。 声明 |
|
|
