微服务架构

微服务架构主讲人：xxx组员：xxx654321CONTENTS微服务的诞生具体应用Monolith微服务架构的优点与缺点微服务的定义微服务架构模式微服务的诞生微服务架构（MicroserviceArchitect）是一种架构模式，它提倡将单块架构的应用划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通。每个服务都围绕着具体业务进行构建，并且能够被独立的部署到生产环境、类生产环境等。背景微服务的诞生并非偶然。它是互联网高速发展，敏捷、精益、持续交付方法论的深入人心，虚拟化技术与DevOps文化的快速发展以及传统单块架构无法适应快速变化等多重因素的推动下所诞生的产物Monolith通常，要开发的服务所对应的代码由多个项目所组成，各个项目会根据自身所提供功能的不同具有一个明确的边界。在编译时，这些项目将被打包成为一个个JAR包，并最终合并在一起形成一个WAR包。接下来，我们需要将该WAR包上传到Web容器中，解压该WAR包，并重新启动服务器。在执行完这一系列操作之后，我们对服务的编译及部署就已经完成了这种将所有的代码及功能都包含在一个WAR包中的项目组织方式被称为Monolith。在项目较小的情况下，这种代码组织方式还是可以接受的：更改完代码后，编译器编译代码，然后软件开发人员花费一分钟部署刚刚编译出来的WAR包以便测试自己刚刚所做的更改。但随着项目的逐渐变大，整个开发流程的时间也会变得很长：即使在仅仅更改了一行代码的情况下，软件开发人员需要花费几十分钟甚至超过一个小时的时间对所有代码进行编译，并接下来花费大量的时间重新部署刚刚生成的产品，以验证自己的更改是否正确。如果应用的部署非常麻烦，那么为了对自己的更改进行测试，软件开发人员还需要在部署前进行大量的环境设置，进而使得软件开发人员的工作变得繁杂而无趣从上面的示意图中可以看到，在应用变大之后，软件开发人员花在编译及部署的时间明显增多，甚至超过了他对代码进行更改并测试的时间，效率已经变得十分低下。在变得越来越大的同时，我们的应用所使用的技术也会变得越来越多。这些技术有些是不兼容的，就比如在一个项目中大范围地混合使用C++和Java几乎是不可能的事情。在这种情况下，我们就需要抛弃对某些不兼容技术的使用，而选择一种不是那么适合的技术来实现特定的功能。除此之外，由于按照Monolith组织的代码将只产生一个包含了所有功能的WAR包，因此在对服务的容量进行扩展的时候，我们只能选择重复地部署这些WAR包来扩展服务能力，而不是仅仅扩展出现系统瓶颈的组成但是这种扩展方式极大地浪费了资源。就以上图所展示的情况为例：在一个服务中，某个组成的负载已经达到了90%，也就是到了不得不对服务能力进行扩容的时候了。而同一服务的其它三个组成的负载还没有到其处理能力的20%。由于Monolith服务中的各个组成是打包在同一个WAR包中的，因此通过添加一个额外的服务实例虽然可以将需要扩容的组成的负载降低到了45%，但是也使得其它各组成的利用率更为低下。可以说，所有的不便都是由于Monolith服务中一个WAR包包含了该服务的所有功能所导致的。而解决该问题的方法就是Microservice架构模式。微服务的定义实际上，从业界的讨论来看,微服务本身并没有一个严格的定义。不过，ThoughtWorks的首席科学家，马丁-福勒先生对微服务的这段描述，似乎更加具体、贴切，通俗易懂：MicroserviceThemicroservicearchitecturalstyleisanapproachtodevelopingasingleapplicationasasuiteofsmallservices,eachrunninginitsownprocessandcommunicatingwithlightweightmechanisms,oftenanHTTPresourceAPI.Theseservicesarebuiltaroundbusinesscapabilitiesandindependentlydeployablebyfullyautomateddeploymentmachinery.Thereisabareminimumofcentralizedmanagementoftheseservices,whichmaybewrittenindifferentprogramminglanguagesandusedifferentdatastoragetechnologies.微服务架构微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通（通常是基于HTTP协议的RESTfulAPI）。每个服务都围绕着具体业务进行构建，并且能够被独立的部署到生产环境、类生产环境等。另外，应当尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建。将功能分散到各个离散的服务中然后实现对方案的解耦。服务更原子，自治更小，然后高密度部署服务微服务架构模式简单地说，Microservice架构模式就是将整个Web应用组织为一系列小的Web服务。这些小的Web服务可以独立地编译及部署，并通过各自暴露的API接口相互通讯。它们彼此相互协作，作为一个整体为用户提供功能，却可以独立地进行扩容。以下图所示的WikiPedia服务架构为例WikiPedia包含了一系列服务，如数据访问服务Databases，搜索服务Search等。这些服务都包含了数量不等的服务实例，以确保能在不同负载的情况下为用户提供优质的服务。在用户的请求到达时，它们将协同工作，一起完成对用户请求的响应在使用Microservice架构模式的情况下，软件开发人员可以通过编译并重新部署单个子服务的方式来验证自己的更改，而不再需要重新编译整个应用，从而节省了大量的时间。同时由于每个子服务是独立的，因此各个服务内部可以自行决定最为合适的实现技术，使得这些子服务的开发变得更为容易。最后如果当前系统的容量不够了，那么我们只需要找到成为系统瓶颈的子服务，并扩展该子服务的容量即可。微服务架构的优点与缺点优点1每个服务足够内聚，足够小，代码容易理解、开发效率提高2服务之间可以独立部署，微服务架构让持续部署成为可能3每个服务可以各自进行x扩展和z扩展，而且，每个服务可以根据自己的需要部署到合适的硬件服务器上4容易扩大开发团队，可以针对每个服务（service）组件开发团队5提高容错性（faultisolation），一个服务的内存泄露并不会让整个系统瘫痪6系统不会被长期限制在某个技术栈上缺点1开发人员要处理分布式系统的复杂性；开发人员要设计服务之间的通信机制，对于需要多个后端服务的usercase，要在没有分布式事务的情况下实现代码非常困难；涉及多个服务直接的自动化测试也具备相当的挑战性服务管理的复杂性，在生产环境中要管理多个不同的服务的实例，这意味着开发团队需要全局统筹（PS：现在docker的出现适合解决这个问题）2应用微服务架构的时机如何把握？对于业务还没有理清楚、业务数据和处理能力还没有开始爆发式增长之前的创业公司，不需要考虑微服务架构模式，这时候最重要的是快速开发、快速部署、快速试错3具体应用目前国外使用微服务架构的知名厂商中不乏Amazon、Twitter、Netflix等这样的科技巨头，但是国内在微服务领域实践这块，真正成功的案例屈指可数，好雨云平台强调应用一键部署，整个平台的核心正是基于微服务的架构去搭建，可以说，好雨云在微服务领域有着成功的经验和技术好雨云是基于“云帮”2.0及主流IaaS厂商资源搭建的、面向业务的新一代公有云服务，同时也是拥有“云帮”2.0全部特性的企业级云应用快速交付及管理平台。用好雨云，让云落地。微服务在好雨云的解决方案好雨云平台的底层是通过Docker实现的，只是用户感受不到Docker。通过这种内部封装,用户不用管理计算资源和网络资源，把复杂技术包装在内部。通过服务整体对外感谢聆听