微服务给传统架构带来哪些改变

Posted 2020-08-07 代码改造世界

微服务给传统架构带来哪些改变

  早在1996年,Gartner最早提出SOA（面向服务架构）的概念，早期的SOA的实现方式主要是WebService，通过契约发布，契约描述，服务实现的流程来构建。早期SOA主要是解决软件与软件之间跨开发语言、跨平台的交互问题。在传统业务中WebService也算是补足业务的通讯问题。

  而微服务（Microservice For SOA+）的提出，则是彻底要改变原有的开发架构，而不是补足作用。由于移动互联网的迅猛发展，开发与迭代速度越来越快。尤其是多个终端，多个平台的业务愈发的迅速发展。传统的单体模式开发架构显然已不和时宜。多个平台功能的不同步性愈发突出。业务与界面耦合性没有彻底解决，并且或多或少的存在维护问题。导致更换界面与迁移平台的成本大幅上升。早期人们就开始想有没有办法解决业务逻辑与平台的分离，他们想到WebService和其他RPC的方式，但是应用过程中发现WebService的私有协议过重，在移动平台上调用显得过于费时费力；那么RPC呢？RPC的标准参差不齐，违背互联网的开放协作原则。简单的说：传统的单体软件没有真正做到一次开发业务，跨设备、跨平台使用。不断重构界面衔接层（MV*中P，VM，C层）的代码，并且业务耦合性没彻底解决。

  微服务油然而生，通过简单的HTTP协议进行服务，抛弃以往又笨又重或者不兼容的服务协议。为了更好使用服务进行交互，人们想起Roy Thomas Fielding在他2000年的提出的RESTful风格的服务架构。通过简单的契约，更快、更好的构建通用的服务。从此业务的互通性得到了很好的解决，不断有公司尝试新的架构。

  通过将业务的调用接口粒度化的暴露出来，用简单的API文档说明业务流程。任何消费端都可以最快的使用业务。不必关系业务细节，从而快速的将业务部署到任何消费端。

  微服务带来一个结果就是：服务端重点关心 Model（BLL与DAL与Entity） 层；客户端重点关心 View 层与 Presenter 或 Controller 或 ViewModel 层；分离了关注点的同时提高了开发效率。

  微服务能像传统业务一样可以部署在任何HTTP的服务器上不需要特殊的机制，并且能很好的利用HTTP协议的特征，只要能理解HTTP的基本特征就可以很快上手使用。

  微服务的特点：将业务逻辑服务化、松散（层级分离）化、版本化、去视图化；垂直的向消费端提供服务；可以集中部署或拆分部署；多个服务可以跑在一个进程或每个服务单独一个进程；可以共用数据库或切分数据库；通过SessionID认证或Token认证或不认证。

  微服务要注意：版本问题、循环依赖问题、日志监视问题。

如图：传统单体架构（紧凑型业务逻辑，多种技术混合使用）

如图：微服务架构（松散型业务逻辑、集中部署或分布式部署、少量技术面面俱到）

如图：微服务的多种部署与管理架构（带来的技术精简，并且以子业务为一个微服务单元）

集中式 - 1

集中式 - 2

分布式 - 1

分布式 - 2

尾巴：

  微服务的浪潮势必改变传统的IT架构，虽然会遇到各种问题，但是趋势决定了未来的走向，微服务的架构灵活性是传统单体架构无法比拟的，既可以集中部署与管理松散的服务又可以分布式部署与管理，不同规模可以对服务的架构有效调整，而不必死板的套用微服务概念。对于传统的开发来说微服务是个巨大的变革，需要一段时间消化与转变思维，我相信微服务是一个大的趋势！

  微服务很有可能成为Web3.0时代的标配，同比现在后端的承载能力反而变强。