| 标题 | 浅谈微服务架构 |
| 范文 | 杨宸 田晴 金新颖 摘 要：在软件开发的过程中，架构是难解的问题。开发一个软件就好比盖造楼房，一个简单的房屋或许不需要架构图来规范它的盖造，但是一座摩天大楼必然需要详细的架构分析图来规范包工队伍的行为，开发一款高质量的软件也不例外。 下面来围绕两个我们认为需要解决的问题来出发，介绍微服务架构在当今互联网环境实现的必要性，以及在当今互联网环境的缺点的解决方案。 关键词：单体架构;垂直拆分架构;分布式架构;面向服务架构;微服务架构;REST风格 一、解决高并发，高可用问题 1.1问题简介 当今世界网民已经达到40亿，早已不是几台服务器就能承担的，根据二八原则80%的用户，在20%的时间点访问网站，如果它的服务器解决不了并发压力，就会降低用户体验。 1.2研究分析 在此问题上，有人提出了对单体架构的水平扩充。但是，根据二八原则80%的业务功能集中在20%的代码，代码的冗余会造成资源的浪费。那该怎么办呢？ 第二个架构垂直拆分架构闪亮登场，它依据业务功能把我们的项目拆分成一个又一个的子项目，从而在解决并发问题上根据我们的业务功能模块进行扩充，节省了资源。但是它的弊端在长期开发中也出现了，他的模块之间是没有通信的。举个例子：一个主要的业务模块依赖于一个并发量较低的权限模块，业务模块不得不编写权限模块的代码，从而浪费了服务器的资源。 之前有Java程序員尝试过用Java的RMI（远程方法调用）来解决这个问题，但是RMI底层使用字节传输的，极容易被黑客伪造，这种架构后来也消失在人们的视野中，但垂直拆分架构一定程度上解决了高并发的问题。 二、开发效率 2.1问题简介 在公司中尤其是面向用户的互联网公司，如果不能按时更新，势必会降低自己的口碑，降低用户体验。因此架构的改变也改变了开发模式的改变。 前面说到为了解决高并发的问题，聪明的软件开发者们把架构垂直拆分，但是也产生了拆分后的项目之间无法通信的问题。 2.2研究分析 第三种主流架构——分布式架构，悠然而生，通过模块之间的鉴权，允许模块之间进行远程通信，开发人员也彻底解放：开发模式不再是十几个人、几百个人对着一个项目改来改去，而是按照模块独立开发，模块之间的调用关系安排专门的人以文档的形式来显示。在很长的一段时期中，这种架构堪称盛行，但很快他的弊病也显示了出来：当模块越来越多时，调用关系错综复杂，系统的耦合度增高，系统难以维护。举个例子：假如你有20个模块，最多有190种通信联系，用户想要改变需求，要求增加新功能，那么在原有的通信关系上加上新的模块和关系将会是一个大工程，这样开发效率不但没有减少，反而随着项目的增加而增大了，因为你要维护复杂的通信关系。同时，当模块集群部署时，怎么控制用户应该去访问的模块呢？ 第四种，面向服务架构（SOA），当服务越来越多、小服务资源逐渐显现，我们需要增加调度中心（常见：Nginx反向代理服务器）来管理集群压力，把用户的请求按访问压力进行路由。这种架构解决了外部需求和内部模块的访问路由，但是仍然没有解决模块内的调度解决方案。 为了解决开发效率以及模块间的通信问题，微服务架构产生了。它规定：1.每一个模块称为一个服务，职责单一;2.对外暴露一种面向资源的REST风格接口，不关心技术的实现;3.自治，每个服务对应一个数据库，小团队自治。我们发现，满足微服务架构的原则就好像云服务的感觉一样，只不过每一个服务都是为了这个项目、这个用户的需求而生的，一个开发团队可以拆分成若干个互不干扰的开发团队一样，实现了开发的解耦，从而大大的提高了开发效率。当然实现微服务架构必然也要处理之前产生的架构问题，并且又出现了新的问题。 在解决服务（之前的模块）之间通信上，因为架构规定每一个服务会对外暴露REST风格接口，因此该架构的技术都提供了一个服务注册中心（比如：只有在滴滴上注册的网约车才能被用户找到），只有在注册中心的服务才能被其他服务找到，并且依赖关系全部由注册中心来管理，这样复杂的通信关系再也不需要人为管理，用户需要添加新的模块我们只需要在注册中心注册一下即可，大大加快了开发的效率。因为服务之间是集群部署，实现微服务架构必须应用负载均衡框架和基于熔断原理的框架，当一个服务挂掉时，路由到集群中其他的服务，当服务集群超过大比例挂掉时熔断器打开，避免影响核心业务服务，这也就是说不仅开发自治，服务也是自治的。举个例子：网上购物时，订单服务挂掉不影响我们把商品加入购物车，这也是微服务的优点之一。 受到SOA的启发，服务外调用服务需要鉴权，服务内之间的调用实际上是第三方注册中心动态代理的，其通信协议基于框架技术的协议，那么意味着内部服务之间也是需要鉴权的。而微服务需要对外暴露REST风格的接口，而该风格最大特点就是无状态性和表属性状态转移。 我们来试想一下：Tomcat服务器需要保留用户登陆的sessionID，客户端cookie中保存登陆信息，以这种状态的保存来判断用户登陆。但是REST风格不允许，我们需要请求通过挂载token（可以理解客户端的身份证）来判断用户登陆的状态，也就是说每一个请求必须有token的存在，那么内部服务调用也需要携带token，那么有20个模块，你就要写20次挂载代码？网关的出现，解决了这个问题，网关拦截所有的内、外部服务请求，实现鉴权，过滤，路由，熔断，代理的功能。网关通过鉴权判断你的请求是否合法，然后路由到对应的服务，服务的REST接口返回到网关动态代理调用，这样我们在网关就可以解决所有的服务之间的逻辑。当然网关也要集群，这样我们还是要沿用SOA架构的形式，用反向代理服务器路由网关即可。 三、结语 本文中，提到了两个问题需要解决。在解决问题途中，提到：提出了对单体架构的水平扩充，但会造成资源的浪费;把架构垂直拆分解决了高并发、高可用问题，但也产生了拆分后的项目之间无法通信的问题;为了解决通信问题，又提出了分布式架构，却容易造成系统难以维护;又有了面向服务架构来解决访问路由;直到微服务架构的产生。我们深入分析了微服务架构在当今互联网环境实现的必要性，提出了其在当今互联网环境的缺点的解决方案。架构的发展是对“摩天大楼”的不断完善，让我们不断向上延申了大楼的高度。 作者简介： 杨宸（2000-）北华航天工业学院计算机学院就读，研究方向软件工程。 田 晴（2002-）北华航天工业学院计算机学院就读，研究方向软件工程。 金新颖（1999-）北华航天工业学院就读，研究方向计算机科学与技术。 |
| 随便看 |
|
科学优质学术资源、百科知识分享平台，免费提供知识科普、生活经验分享、中外学术论文、各类范文、学术文献、教学资料、学术期刊、会议、报纸、杂志、工具书等各类资源检索、在线阅读和软件app下载服务。