里高级技术专家带你看透微服务的来龙去脉

所谓的微服务是SOA架构下的最终产物，该架构的设计目标是为了肢解业务，使得服务能够独立运行。

微服务设计原则：1、各司其职 2、服务高可用和可扩展性

概念还是比较抽象的，接下来，我将从单体应用开始，讲解为什么会有微服务以及什么是微服务。

一、单体应用

在初期，互联网公司的应用技术栈大致分为 LAMP(Linux + Apache + MySQL + PHP)和 MVC(Spring + iBatis/Hibernate + Tomcat)两大流派。两者都是为单体应用架构设计的，其优点是学习成本低，开发上手快，测试、部署、运维也比较方便。

以 MVC 架构为例，业务通常是通过部署一个 War 包到 Tomcat 中，然后启动 Tomcat，监听某个端口即可对外提供服务。早期在业务规模不大、开发团队人员规模较小的时候，采用单体应用架构，团队的开发和运维成本都可控。


 

业务规模的不断扩大，团队开发人员的不断扩张，单体应用架构就会开始出现问题，大概会有以下几个方面的问题。

部署效率低：当单体应用的代码越来越多，依赖的资源越来越多时，应用编译打包、部署测试一次，甚至需要 10 分钟以上。

团队协作开发成本高：当团队人员扩张，多人修改代码，然后一起打包部署，测试阶段只要有一块功能有问题，就得重新编译打包部署，然后重新预览测试，所有相关的开发人员又都得参与其中，效率低下，开发成本极高。

系统高可用性差：因为所有的功能开发最后都部署到同一个 War 包里，运行在同一个 Tomcat 进程之中，一旦某一功能涉及的代码或者资源有问题，那就会影响整个 WAR 包中部署的功能。

线上发布变慢：一旦代码膨胀，服务启动的时间就会变长。因此，急需一种方法能够将应用的不同模块的解耦，降低开发和部署成本。

想要解决上面这些问题，服务化的思想也就应运而生。

二、服务化

服务化就是把传统的单机应用中通过 JAR 包依赖产生的本地方法调用，改造成通过 RPC 接口产生的远程方法调用。在编写业务代码时，对于通用的业务逻辑，把它抽象并独立成为专门的模块，对于代码复用和业务理解有很大的好处。

以微博系统为例，微博既包含了内容模块，也包含了消息模块和用户模块等。其中消息模块依赖内容模块，消息模块和内容模块又都依赖用户模块。当这三个模块的代码耦合在一起，应用启动时，需要同时去加载每个模块的代码并连接对应的资源。一旦任何模块的代码出现 bug，或者依赖的资源出现问题，整个单体应用都会受到影响。

为此，首先可以把用户模块从单体应用中拆分出来，独立成一个服务部署，以 RPC 接口的形式对外提供服务。微博和消息模块调用用户接口，就从进

（编辑：广元站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!