微服务技术调研和实践.docxVIP

微服务技术调研与实践微服务架构简介微服务架构模式（Microservices Architecture Pattern）的目的是将大型的、复杂的、长期运行的应用程序构建为一组相互配合的服务，每个服务都可以很容易得局部改良。微服务（micro services）这个概念不是新概念，很多公司已经在实践了，例如亚马逊、Google、FaceBook，在国内我自己知道的有：BAT、滴滴、饿了么、携程、唯品会、酷狗等公司。一个单体应用可能是下图这样的架构，各个功能在应用内部通过模块划分，这样的应用有它自己的好处如：调试简单、部署方便等。但是它也有明显的局限性，如：不同模块发生资源冲突时无法解决（有些业务需要无阻塞的io操作，这明显使用nodejs之类的语音是非常棒的，但是有些业务需要做算法密集型的操作，这明显就是nodejs的短板，这时候单体应用就需要做一个妥协，而不能都取最优解）。单体应用一般所有应用都运行在同一进程中，在某个模块产生bug后会导致整个应用挂掉。其中最突出的是，随着时间的迁移这个应用会越来越大，会大到任何单个开发者都不可能搞懂它。将上图单体应用拆分为微服务的架构如下：从图中可以看到每一个模块功能都变成了一个单独的服务，各服务之间通过各自暴露的API 接口相互调用，对外的接口通过一个API GATEWAY 来统一处理。这种架构看起来明显是稍显复杂，但是其扩展性却是非常棒的，下图很好的描述如何去构建和扩展一个微服务架构。X轴表示在物理层面做负载均衡、应用副本来提高吞吐能力。Y轴表示从功能方面拆分服务，来对应处理单一专注功能。Z轴表示如何通过优化路由来整合相关服务（API GATEWAY）微服务架构的优势与不足优点：每个服务足够内聚，足够小，代码容易理解、开发效率提高服务之间可以独立部署，微服务架构让持续部署成为可能；每个服务可以各自进行x扩展和z扩展，而且，每个服务可以根据自己的需要部署到合适的硬件服务器上；容易扩大开发团队，可以针对每个服务（service）组件开发团队；提高容错性（fault isolation），一个服务的内存泄露并不会让整个系统瘫痪；系统不会被长期限制在某个技术栈上。缺点开发人员要处理分布式系统的复杂性；开发人员要设计服务之间的通信机制，对于需要多个后端服务的user case，要在没有分布式事务的情况下实现代码非常困难；涉及多个服务直接的自动化测试也具备相当的挑战性；服务管理的复杂性，在生产环境中要管理多个不同的服务实例，意味着开发团队需要全局统筹（docker的出现适合解决这个问题）API Gateway如果已经使用微服务架构系统，客户端调用各个服务的使用场景可能是这样的：想象一下，各个服务部署在不同的服务器上，那客户端调用是否就需要记录无数个baseurl，这还算好的。如果某一项功能需要同时调用多个服务来获取一个组合数据，那是否就需要发起N个HTTP请求，这对于客户端肯定噩梦。所以我们需要 API GATEWAY从图中可以直接看出 API GATEWAY 的直接作用为请求转发、合成等。客户端的请求都需要经过 API GATEWAY 先进行处理。这还只是 API GATEWAY 的基本功能，一个合格的 API GATEWAY还有许多功能需要处理：统一身份认证、权限配置恶意访问限制日志统一管理服务器健康检查缓存处理...添加 API GATEWAY 前后对比的用例图：如果有对应的研发实力，如果不记成本和实力考虑的话可以自己开发一套完整的 API GATEWAY，当然开源界也有一些造好的轮子可以使用：Kong基于Nginx 使用lua插件方式开发的 API GATEWAY ,上面介绍的功能基本上通过配置能够完成。除了API组合，我询问了开发组，他们的回答是：Kong致力于开发一套外部API route，只完成相关流程处理和公共组件，关于组合API建议各个项目创建一个内部API GATEWAY 来专门处理对应的服务组合，然后通过Kong来路由转发。通信方式由于各个服务间是相互独立的，如果服务之间需要相互访问，那就不免要处理进程间的通信了。在微服务间进行通信业界推荐采用一下几种方式：同步：RPC、REST异步：AMQP、STOMPRPCRPC(Remote Procedure Call，远程过程调用), RPC其实也是种C/S的编程模式，有点类似C/S Socket 编程模式，但要比它更高一层,通过RPC可以充分利用非共享内存的多处理器环境,应用程序就像运行在一个多处理器的计算机上一样。可以方便的实现过程代码共享，提高系统资源的利用率，也可以将以大量数值处理的操作放在处理能力较强的系统上运行，从而减轻前端机的负担。同样，RPC是一套标准的模式，可按照既定的协议去自主实现，但是我还是建议采用先用轮子去做会