认识达内从这里开始

微服务架构技术随着互联网的不断发展而被越来越多的程序员掌握并应用到不同软件开发项目之中，而本文我们就通过案例分析来简单了解一下，微服务架构基础知识分享。

一、对微服务架构的理解

1.1微服务架构

微服务架构，主要是多了个“微”。亚马逊有个粗粗的定义：一个微服务应用工程的所有开发、测试、运维加起来大约6到8个人，只需要两个披萨就可以聚餐了。

反例：不是一个Service类组成的应用工程，发布成服务就是微服务。这样分的太小，理解微服务就很片面。杭州某金融大厂，曾经分的很细，造成了运维测试成本巨大。开始分了合，折腾...

1.2为啥需要微服务?

由SOA架构->微服务架构的转变，得理解为什么微服务架构被广泛提到并实践。它解决了什么问题，带来了什么价值?

传统企业或者很多企业的软件，大多不止一套系统，都是各个独立大系统的堆砌。整体存在的问题是：

扩展性差

可靠性不高

维护成本还很大

重复轮子很多

那么这些问题，可以想到的解决方案就是：

组件化

服务化

微服务架构，将各个组件或者模块分散到各个服务中，对整个系统实现解耦。那微服务架构强调的重中之重就是业务系统需要完善的组件化和服务化。什么是组件化?

组件化，即将一个大系统，按照一定的业务或者技术维度关注形式，拆分成独立的组件。目的是为了分而治之，为了可重用，为了减少耦合度。比如按照技术维度：搜索组件、缓存组件;按照业务维度：用户中心、支付中心等。

二、服务化前的问题

2.1没有服务化，不代表不是分布式或集群

分布式，就是多个实例提供相同的服务。比如多个地方动车站里面，多个机器提供取票服务。多个地方，北京上海等，就是多机房，多个取票服务一起组成了集群，形成分布式服务。那啥是服务化?

服务化，强调“化”!核心就是不同服务之间的通信。是一种以服务为中心的解决方案：

服务注册

服务发布

服务调用

服务监控

服务负载均衡

等等

2.2没有服务化的架构问题

没有服务化前，举个例子，会更形象：

假设有个取票服务、买票服务、改座服务都需要验证下用户身份真实性，那么会存在下面的问题：

取票服务->调用用户DB代码->用户DB

买票服务->调用用户DB代码->用户DB

改座服务->调用用户DB代码->用户DB

明显的问题是：

代码重复：不同业务相同访问DB的userDAO代码逻辑。而且每个服务这块代码是不同人维护的。

可维护性低：不同人维护;不同地方维护;每次DB字段改变或者迁库，全部业务都有修改

DB访问耦合

自然也有解决方案是：lib。维护一个user-DAO-lib1.0.0release包，给各个业务方。

解决了问题，引入了新的问题，lib升级是巨大而又漫长的问题。比如小李是维护user-DAO-lib的人，有一次写了隐蔽的bug。user-lib升级到了1.0.1release，花了1个月左右时间，推几十个业务方升级完毕。然后这个bug运行了几天出现了，考虑升级fix或者回滚都是巨大的成本

基于服务化，就可以完美解决问题。

【免责声明】：本内容转载于网络，转载目的在于传递信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请加抖音太原达内IT培训学习了解。