微服务架构及相应云平台解析.doc

微服务架构及相应云平台解析 　　摘 要 本文介绍了主要软件服务的设计架构，分析了新兴的微服务架构，并对其实现的先决条件――容器化技术进行了研究。文章还分析了两种微服务架构在云服务中的实现形式 关键词 服务架构 微服务 容器 CaaS BaaS 中图分类号：TP309 文献标识码：A DOI：10.16400/ki.kjdkx.2017.01.013 1网络服务架构 现在社会的各行各业均无法离开网络服务系统，例如学校有学生管理系统、教务系统等；企业有人事系统、财务系统、客户关系管理系统等；手机上运行的各种APP以及游戏，都要与后台服务器相连接，接受后台系统的服务 软件系统的服务主要是为软件的功能提供支持，以及为其它的服务提供接口。随着网络的普及，软件的服务与软件本身往往是分离的，服务由网络上的服务器提供（后台），而软件运行在本地或浏览器上（前端），后台服务是软件开发中最关键的部分 1.1单体服务架构 上世纪90年代以前的软件服务多为单体架构，所有的功能采用集成化、过程化的开发，之后被编译为一个文件并放置于容器中运行，这种架构易于开发、部署和测试，但其主要问题包括：（1）代码集成在一起，几乎无法协同开发。（2）代码功能高度耦合，后期维护、功能扩展困难。后期系统业务变更或服务整合会导致整个系统需要重构，大幅提高IT实施的成本。（3）小修改就可能导致重构整个项目，迭代时间大幅提升。（4）稳定性差，由于系统高度集中在一起，任何一个小的问题可能导致整个系统瘫痪 1.2 SOA架构 随着软件的模块化概念开始流行，一种被称为面向服务的架构（SOA，Service Oriented Architecture）在2000年后被软件企业广泛应用。SOA架构基于服务（即基于模块化的组件），服务提供接口，服务间可通过XML进行信息交换。SOA基本架构包含ESB（Enterprise Service Bus），Web服务、XML和SOAP。SOA的最大特征就是松耦合，结合分层次的开发理念，解决了协同开发、测试等问题，也更易于后期扩充功能。但SOA本身只是一个架构，并非实施标准，所以在生产环境中应用SOA存在一些问题： （1）需要共享ESB，松耦合服务实际边界非常模糊，修改某一模块会导致需要修改其它模块，从而导致代码维护困难，系统迭代速度大幅降低。（2）系统后期扩充将导致系统臃肿、性能下降；某些功能扩充甚至需要部分重构ESB及其它服务。（3）系统开发长期被一种开发技术绑定，开发人员、技术、架构变更的灵活度大幅下降 2微服务架构 微服务架构并非一个全新概念，它更像是SOA架构的一种实现。微服务架构依然是面向服务，但是其将松耦合做到了极致。该架构是去中性化的，其中没有ESB，每一个服务可以单独开发、测试、运行和部署，甚至能够有自己的数据库。服务间的通信与开发语言无关，一般采用基于HTTPs 的RESTful API（Representational State Transfer API）。微服务的出现顺应了敏捷开发的浪潮，先开发先上线，后开发再扩充，能对系?y进行快速迭代。微服务架构有以下特点： （1）服务小：每一个服务代码量少、复杂度低，仅专注某一项功能。（2）能够独立运行：每个服务可以运行在独立的进程中。（3）与语言无关的通信机制：例如XML、JOSN、REST API等。（4）松耦合：开发、部署和运行均处于独立状态，几乎无外部依赖。（5）去中心化：没有ESB，可完全分布式部署。（6）数据独立：微服务可以有自己的数据库，其它服务只能通过接口获得该服务的数据 2.1 微服务架构的优势 根据微服务以上的特性，实施过程中有如下优势： （1）依照服务来划分开发团队：每一个服务对应一个完整团队（包含后台、前端、数据库、中间件等），从开发、测试、上线及后期维护均由该团队负责，一个跨职能的团队能够完全掌控自己的微服务 （2）服务的异构性：能够针对不同业务选择合适的开发方案、开发语言、框架及部署环境，无须像单体或是SOA架构一样，选择统一的技术方案。在传统架构中，初期技术方案一旦选定，很长时间内，整个系统就会在所选技术框架内进行开发，到了后期想要尝试新的技术，则有很大可能要重构系统，不但开发难度大，而且项目越大，失败风险越高。而微服务架构采用的是独立的扩展方式，不但无须重构原系统，还可以极小风险测试新的服务，一旦新服务达不到预期，则可直接终止，这也仅仅是停止使用一个服务而已，对整个系统影响极小 （3）独立测试、部署及容错能力：可以对微服务进行单独的测试和部署，无须对整个系统进行测试、编译和从新部署，降低了系统运行风险。当一个微服务出现运行故障时，不会影响系统中其它的服务，避免了系统