마이크로 서비스 아키텍처의 장점과 단점 -1 수 (rpm)

"크리스 리처드슨 시리즈 마이크로 서비스"마이크로 서비스 아키텍처의 강점과 약점

편집자 주 | Nginx의 공식 블로그에서 문서, 서비스는, 최초의 마이크로 일련의 기존의 모 놀리 식 애플리케이션의 단점뿐만 아니라 장점과 마이크로 서비스 아키텍처의 문제에 초점을 맞추고 있습니다.

 에서 전송 http://blog.daocloud.io/microservices-1/

저자 : 크리스 리처드슨은 세계 최고의 소프트웨어 전문가, "POJO이며 IN ACTION"책 예술의 고전 작품의 저자뿐만 아니라 cloudfoundry.com 원래 설립자 등 크리스 리처드슨과 마틴 파울러, 샘 뉴먼, 아드리안 한 Cockcroft 및 호출 세계 10 대 소프트웨어 아키텍트.

모든 기사는 크리스 리처드슨 독점 라이센스 DaoCloud 번역과 출판에 의해 작성되었습니다.

이 문제에


마이크로 서비스는 총회 핫스팟의 기사, 블로그, 소셜 미디어 토론 및 프리젠 테이션으로, 순간의 광범위한 우려를 발생, 가트너의 "마약 중독 사이클은"매우 앞 순위에. 동시에, 또한 마이크로 서비스에 의문을 제기 한 소프트웨어 커뮤니티는 새로운 것이 아니다. 반대 만 마이크로 서비스 SOA (지향 아키텍처 서비스) 두 번째 포장을 주장한다. 그러나 추구하거나 의문을 제기 여부, 마이크로 서비스 아키텍처는 큰 장점을 가지고, 특히, 애자일 개발하고 복잡한 엔터프라이즈 애플리케이션의 전달이 가능하게 할 수 있습니다.

이 시리즈는 기존의 단일 아키텍처에 비해 마이크로 서비스, 빌드 및 배포의 디자인을 다루는 일곱 개 기사를 포함합니다. 이 시리즈는 또한 프로젝트에 적합한 마이크로 서비스 아키텍처 모델의 장단점을 이해하고, 어떻게 적용하는 것, 다양한 요인 마이크로 서비스 아키텍처를 분석합니다.

크리스 리처드슨 전체 시리즈 마이크로 서비스 7 :

1. 마이크로 분석 서비스 아키텍처의 개념

마이크로 서비스 아키텍처 2. 건설 : API 게이트웨이를 사용하여

3. 심층 프로세스 간 통신 서비스 아키텍처 마이크로

서비스 검색 및 실천 사례 4. 실행 가능한 옵션

5. 이벤트 구동 마이크로 데이터 관리 서비스

6. 마이크로 서비스 배포 전략

7. 단량체 마이크로 서비스 애플리케이션으로 변환

먼저, 계정에 마이크로 서비스를 원하는 이유를 이해할 수 있습니다.

하나의 응용 프로그램의 건설

우리 동네 짱과 Hailo 택시 소프트웨어와 새로운 경쟁을 개발하려는 가정하자. 사전 회의 및 요구 사항을 완료 한 후, 당신도 필요 수동으로 새 프로젝트를 만들 수 있습니다, 또는 당신이 생성하는 레일, 봄 부팅, 재생 또는 메이븐을 사용할 수 있습니다. 아래에 도시 된 바와 같이, 새로운 애플리케이션 프레임 워크 모듈은, 육각형을 취할 수있다 :

리처드슨 - microservices-part1-1_monolithic 아키텍처

서비스에 의해 정의되는 핵심 애플리케이션의 비즈니스 로직은 도메인이 개체 및 각 모듈을 완료하는 이벤트. 코어 및 외부 상호 주위 다양한 어댑터. 어댑터는 조립 데이터베이스 액세스, 메시지 생성 등의 정보 구성 요소를 소비하고 액세스 할 수있는 웹 지원 모듈을 사용자 인터페이스 나 API를 제공한다.

주의 논리 모듈 형 디자인에도 불구하고, 전체 응용 프로그램은 전체 포장 및 배포에 적용 할 실제 언어 별 형식과 프레임 워크는 아직도있다. 예를 들어, 많은 자바 애플리케이션 톰캣이나 부두 등의 응용 프로그램 서버에 배포 된 WAR 파일로 포장됩니다. 일부 Java 응용 프로그램 자체는 패키지의 JAR 곰. 마찬가지로, 레일 및 Node.js를 응용 프로그램 디렉토리 계층 구조를 통해 포장됩니다.

이 스타일을 사용하는 응용 프로그램은 매우 일반적입니다. 때문에 좋은 IDE 및 단일 응용 프로그램을 구축하기 위해 다른 도구, 이러한 응용 프로그램을 배포하기 쉽습니다. 이러한 응용 프로그램은 테스트에 매우 쉽습니다. 당신은 아주 쉽게 셀레늄 테스트 UI를 사용하여 테스트 종료 종료 할 수 있습니다. 전체 응용 프로그램은 단순히 서버에 패키지를 복사, 배포하기 쉽습니다. 또한 여러 개의 확장 팩 및로드 밸런싱을 실행하여 달성 될 수있다. 초기 프로젝트에서 매우 효과적 않습니다.

아키텍처에 지옥 모노머

불행하게도,이 간단한 방법은 큰 한계가있다. 성공적인 응용 프로그램은 결국 시간이 지남에 큰 될 것입니다. 각 스프린트 단계에서, 개발 팀은 코드의 새로운 라인의 번호를 추가합니다. 몇 년 후, 원래 작고 간단한 응용 프로그램이 비 대한 될 것입니다. 극단적 인 예를 제공하기 위해, 나는 최근 개발자와 통신, 그는 JAR 파일의 수천 (코드 만 몇 줄 포함) 애플리케이션의 의존성을 분석 할 수있는 작은 도구를 개발하고있다. 나는 매년 개발자의 많은 문제가 이런 종류의 처리하는 노력을 아끼지 않았다가 있다고 생각합니다.

一旦你的应用变得庞大、复杂,你的开发团队将饱受折磨,苦苦挣扎于敏捷开发和交付。一大原因就是应用已经格外复杂,庞大到任何一个开发者都无法完全理解。最后,修复 bug 和实施新功能也就极其困难且耗时颇多。更可怕的是,这是一个向下的螺旋发展。代码库越难理解,正确的修改就越难。最后你会深陷庞大的、无法估量的泥淖之中。

而这种应用的尺寸也会拖慢开发进度。应用越大,启动时间越长。譬如在最近的调查中,不少开发者指出启动时间长达 12 分钟。我也听说有的应用启动时间居然得 40 分钟。如果开发者不得不频繁重启应用服务器,那大量时间就被浪费,生产效率也饱受其害。

庞大且复杂的单体应用的另一大问题就是难以进行持续部署。现在, SaaS 应用的发展水平足以在单日内多次将修改推送到生产环境。然而要让复杂的单个应用达到此水平却极为棘手。想更新应用的单个部分,必须重新部署整个应用,漫长的启动时间更是雪上加霜。另外,由于不能完全预见修改的影响,你不得不提前进行大量人工测试。结果就是,持续部署变得不可能。

如果单体应用的不同模块在资源需求方面有冲突的话,那应用的扩展也很难。比如,模块之一需要执行 CPU-intensive 图像处理逻辑,最好部署到 AWS 的 EC2 Compute Optimized instances;而另一模块需要内存数据库,最好适配 EC2 Memory-optimized instances。由于这两个模块需要共同部署,你不得不在在硬件选择方面做妥协。

单体应用的另一问题就是可靠性。由于所有模块都运行在同一进程中,任何模块中的一个 bug,比如内存泄漏都可能弄垮整个进程;此外,由于应用中的所有实例都是唯一,这个 bug 将影响整个应用的可用性。

最后,单体应用会让采用新框架和语言极其困难。举例来说,你有两百万行使用 XYZ 框架的代码,如果要使用 ABC 框架重写代码,无论时间还是成本都将非常高昂,即便新框架更好。这也就成为使用新技术的阻碍。

总结:这个一开始曾经成功关键业务应用,最终却变成一个臃肿的、无法理解的庞然大物。它使用老旧、陈腐、低效的技术,几乎吸引不到出色的开发者。这个应用非常难于扩展,也不稳定可靠。最终,敏捷开发和交付几乎成为不可能。

你该何去何从?

微服务——直击痛点

诸如亚马逊、eBay、Netflix 等公司已经通过采用微服务架构范式解决了上文(第一部分)提到的问题。不同于构建单一、庞大的应用,微服务架构将应用拆分为一套小且互相关联的服务。

一个微服务一般完成某个特定的功能,比如订单管理、客户管理等。每个微服务都是一个微型应用,有着自己六边形架构,包括商业逻辑和各种接口。有的微服务通过暴露 API 被别的微服务或者应用客户端所用;有的微服务则通过网页 UI 实现。在运行时,每个实例通常是一个云虚拟机或者 Docker 容器。

对于前文所述的系统,一种可能的系统分解图如下:

리처드슨 - microservices-part1-2_microservices 아키텍처

应用的每个功能区都由其自身微服务实施。此外,整个网页应用被拆分为一套简单的网页应用(比如我们的打车软件拆分为乘客应用和司机应用),从而能够轻松地针对特定用户、设备或者用户案例进行单独部署。

每个后端服务包括一个 REST API 和由其它服务提供的服务消耗 API。例如,司机管理服务使用“通知”服务器来告知司机即将的行程。UI 服务唤醒其它服务,从而呈现网页。这些服务也可能用到基于信息的异步通信。内部服务通信会在本系列文章中详述。

有的 REST API 也对司机和乘客的移动应用开放。这些应用并不能直接访问后端服务器,相反,通信由名为 API Gateway 的中间人调解。AIP Gateway 负责负载均衡、缓存、访问控制、API 计费、监控等,通过 NGINX 高效实施。本系列的后续文章将会讲解 API Gateway。

리처드슨 - microservices-part1-3_scale 큐브

上图是 Scale Cube 的 3D 模型,来自《The Art of Scalability》 一书。微服务架构范式对应 Y 轴,X 轴由负载均衡器后端运行的多个应用副本组成,Z 轴(数据分割)将需求路由到相关服务。

应用通常同时使用这三种不同类型的扩展。Y 轴扩展将应用分解为如图一(https://www.nginx.com/wp-content/uploads/2015/05/Graph-031-e1431992337817.png)所示的微服务。在运行时维度,X 轴扩展在输出和可用性的负载均衡后运行多个实例。部分应用会使用 Z 轴扩展来对服务进行数据分割。下图展示了行程管理服务(Trip Management)是如何使用 Docker 部署到 AWS EC2 上的。

리처드슨 - microservices-part1-4_dockerized - 응용 프로그램

在运行时,行程管理服务包括多个服务实例,每个服务实例都是一个 Docker 容器。为了实现高可用性,这些容器运行在多个云虚拟机上。在应用实例前面是 NGINX 这样的负载均衡,将请求分发给全部实例。负载均衡也可以处理缓存、访问控制、 API 测量和监控等。

微服务架构范式对应用和数据库的关系影响巨大。每个服务都有自身的数据库计划,而不与其它服务共享同一个数据库。一方面,这个方法类似企业级数据模型。同时,它也导致部分数据的重复。然而,要想从微服务中获益,为每个服务提供单个的数据库计划就非常必要,这能保证松散耦合。下面的图表展示了示例应用的数据库架构。

소개 - microservices

每个服务都有其自己的数据库。此外,单个服务可以使用符合自己需要的特定类型的数据库,即多语言一致性架构。例如,为了发现附近乘客,驾驶员管理服务必须使用高效支持地理位置请求的数据库。

表面上看,微服务架构范式与 SOA 非常类似,这两种架构都包括一套服务。然而,微服务架构范式被看作不包含某些功能的 SOA 。这些功能包括网络服务说明( WS-* )和 Enterprise Service Bus (ESB) 的商品化和请求包。基于微服务的应用更青睐 REST 这样简单的、轻量级的协议,而不是 WS-* 。他们也极力避免在微服务中使用 ESBs 及类似功能。微服务架构范式也拒绝 SOA 的其它部分,比如 canonical schema 的概念。

微服务架构的好处

微服务架构模式有很多好处。首先,通过分解巨大单体应用为多个服务方法解决了复杂性问题。在功能不变的情况下,应用被分解为多个可管理的分支或服务。每个服务都有一个用 RPC- 或者消息驱动 API 定义清楚的边界。微服务架构模式给采用单体式编码方式很难实现的功能提供了模块化的解决方案,由此,单个服务很容易开发、理解和维护。

第二,这种架构使得每个服务都可以有专门开发团队来开发。开发者可以自由选择开发技术,提供 API 服务。当然,许多公司试图避免混乱,只提供某些技术选择。然后,这种自由意味着开发者不需要被迫使用某项目开始时采用的过时技术,他们可以选择现在的技术。甚至于,因为服务都是相对简单,即使用现在技术重写以前代码也不是很困难的事情。

第三,微服务架构模式使得每个微服务独立部署,开发者不再需要协调其它服务部署对本服务的影响。这种改变可以加快部署速度,譬如 UI 团队可以采用 AB 测试并快速部署变化。微服务架构模式使得持续化部署成为可能。

最后,微服务架构模式使得每个服务独立扩展。你可以根据每个服务的规模来部署满足需求的实利。甚至于,你可以使用更适合于服务资源需求的硬件。比如,你可以在 EC2 Compute Optimized instances 上部署 CPU 敏感的服务,而在 EC2 memory-optimized instances 上部署内存数据库。

微服务架构的不足

Fred Brooks 在 30 年前写道 “there are no silver bullets”,像任何其它科技一样,微服务架构也有不足。其中一个跟他的名字类似,“微服务”强调了服务大小,实际上,有一些开发者鼓吹建立稍微大一些的,10-100 LOC服务组。尽管小服务更乐于被采用,但是不要忘了微服务只是结果,而不是最终目的。微服务的目的是有效的拆分应用,实现敏捷开发和部署。

另外一个不足之处在于,微服务应用是分布式系统,由此会带来固有的复杂性。开发者需要在 RPC 或者消息传递之间选择并完成进程间通讯机制。此外,他们必须写代码来处理消息传递中速度过慢或者不可用等局部失效问题。当然这并不是什么难事,但相对于单体式应用中通过语言层级的方法或者进程调用,微服务下这种技术显得更复杂一些。

另外一个关于微服务的挑战来自于分区的数据库架构。同时更新多个业务主体的事务很普遍。这种事务对于单体式应用来说很容易,因为只有一个数据库。在微服务架构应用中,需要更新不同服务所使用的不同的数据库。使用分布式事务并不一定是好的选择,不仅仅是因为 CAP 理论,还因为当前高扩展性的 NoSQL 数据库和消息传递中间件并不支持这一需求。最终你不得不使用一个最终一致性的方法,从而对开发者提出了更高的要求和挑战。

测试一个基于微服务架构的应用也是很复杂的任务。比如,对于采用流行的 Spring Boot 架构的单体式 web 应用,测试它的 REST API,是很容易的事情。反过来,同样的服务测试需要启动与它有关的所有服务(至少需要这些服务的 stubs)。再重申一次,不能低估了采用微服务架构带来的复杂性。

另外一个挑战在于,微服务架构模式应用的改变将会波及多个服务。比如,假设你在完成一个案例,需要修改服务A、B、C,而 A 依赖 B,B 依赖 C。在单体应用中,你只需要改变相关模块,整合变化,部署就好了。对比之下,微服务架构模式就需要考虑相关改变对不同服务的影响。比如,你需要更新服务 C,然后是 B,最后才是 A。幸运的是,许多改变一般只影响一个服务,而需要协调多服务的改变很少。

部署一个微服务应用也很复杂,一个单体应用只需要在复杂均衡器后面部署各自的服务器就好了。每个应用实例是需要配置诸如数据库和消息中间件等基础服务。相比之下,一个微服务应用一般由大批服务构成。根据 Adrian Cockcroft 的分享,Hailo 由 160 个不同服务构成,而 NetFlix 则超过 600 个服务。每个服务都有多个实例,这就形成大量需要配置、部署、扩展和监控的部分。除此之外,你还需要完成一个服务发现机制(后续文章中发表),以用来发现与它通讯服务的地址(包括服务器地址和端口)。传统的解决问题办法并不能解决这么复杂的问题。最终,成功部署一个微服务应用需要开发者有足够的控制部署方法,并高度自动化。

自动化的方法之一是使用譬如 Cloud Foundry 这样的 PaaS 服务。PaaS 能让开发者轻松部署和管理微服务,让他们无需为获取并配置 IT 资源劳神。同时,配置 PaaS 的系统和网络专家可以采用最佳实践和策略来简化这些问题。另外一个自动部署微服务应用的方法是开发自己的基础 PaaS 系统。通常的起步方式是 Mesos 或 Kubernetes 这样的集群管理方案,配合 Docker 使用。作为一种基于软件的应用交付方法,NGINX 能够方便地在微服务层面提供缓冲、权限控制、API 统计、以及监控。我们会在后续的文章中分析它如何解决这些问题。

总结

构建复杂的应用的确非常困难。单体式的架构更适合轻量级的简单应用。如果你用它来开发复杂应用,那真的会很糟糕。微服务架构模式可以用来构建复杂应用,当然,这种架构模型也有自己的缺点和挑战。

在后续的博客中,我会深入探索微服务架构模式,并讨论多个话题,包括服务发现、服务部署选择、以及将单体应用拆分为多个服务的策略。

下期题目:构建微服务架构:使用 API Gateway ,敬请期待!

阅读英文原文:https://www.nginx.com/blog/introduction-to-microservices/#rd?sukey=fa67fe3435f5c4beec6f6cb43b96b08f1bd5e81949c8ff8b1378a0b2b94608dce9afd0ef72370c53e80e111d7ff9595f

 

This entry was posted in 干货 and tagged . Bookmark the permalink.

Post navigation

7 thoughts on “「Chris Richardson 微服务系列」微服务架构的优势与不足”

추천

출처www.cnblogs.com/long2050/p/12079929.html