解读Microservices

Posted 2021-04-24 BitTiger

现在很多人都在谈论Microservices，但是每当我们努力探究的时候，似乎里面没有任何新东西，每个人都在讨论，却没有人知道如何去做。那现在我们来看一看Microservices到底是什么。

从开发的角度来看

从开发的角度来说，Microservices对应胖服务，下图中左边是胖服务，右边是Microservices微服务。胖服务里面往往把所有服务都放在一起来开发，强调了模块之间的相互牵连，也就是所谓的“牵一发而动全身”。而右边的微服务则相对独立，能够使用不同的语言来进行开发。

 

从部署的角度来看

在部署的时候可以看到，胖服务在每个机器里面都需要把所有模块包含在里面，所以整个胖服务之间都是一样的。而在微服务里，我们可以把每个模块和每个服务部署在多个机器上，而每个机器上甚至可以部署多个一样的服务

 

 

Microservices是一个新概念吗？

那Microservices到底是一个新的概念吗？肯定不是。从service-oriented architecture角度来看，实际上它就是一种面向服务的设计。因此，我们的Microservices微服务只是SOA小小的子集。那我们是在不断地创造新概念来满足虚荣心吗？实际上，很多时候我们会有很多花哨的成分在里面，但对于微服务来说，它选择了面向服务这一个子集，也就是说在这个子集里它有一些独到之处。

 

 

Microservices的趋势

那这些独到之处有哪些呢？我们可能很难定义出微服务到底是什么，但我们可以从下面七个趋势中看一看微服务到底带给我们什么

• 组件是服务

• 基于需求模块的团队

• 弱化管道强调终端

• 分散管理

• 部署自动化

• 为失败设计

• 进化的设计

 

趋势一  

组件是服务，我们想要了解组件是什么，组件其实是一些相互独立，能够相互替代并且能够独立升级的东西。举个例子，我们有笔记本，有显示器，有鼠标，有键盘，这些放在一起组成了工作套装，它是能够相互替代的，因为笔记本和显示器都可以替代成别的东西。那什么叫独立升级呢？比如说把我的显示器从20寸升级到24寸，这就是一种独立升级。

 

那再看一看怎么实现组件呢？

 

实际上有两种方式，左边是基于Library库函数的方式。它的核心往往是一种语法调用，比如函数或者类的写法。而右边是基于服务的方式，那它的方式往往是进程间的通信，如今http之类的基于web的通信已经越来越成为我们一个实时标准了。

 

 

右侧有什么好处呢？比如说某个库升级了，需要依赖于Java8，而其它旧的库需要依赖于Java7，那左边基于库的方式就很难实现，因为它们往往需要依赖同一个版本。而基于右边微服务的方式就很容易实现。实际上再结合现在Docker越来越火的趋势，在不同的Docker里打装上不同的Java运行版本就很容易实现。

趋势二  

基于需求模块的团队这个看起来很抽象，传统来说，团队里面的分工就是UI团队，Server团队，DBA团队，但我们如果基于微服务拆解以后就会发现，这群人负责Order,另群人负责做Shipping，还有一群人负责做类目Catalog，所以不同的人群可以组合在一起实现一个小团队。像很多创业公司都是这样做的，就会拆成这样的情况。

 

趋势三  

弱化管道强调终端什么叫弱化管道呢？其实传统的方式我们也能把服务都连在一起，但这些服务中间连接的集合体往往会做很多事情，比如check一些消息，判断怎么路由以及大家真正的连接等各种复杂情况，都需要给中间键来解决 。而如今随着大家的通讯方式越来越简单，我们可以在每一个单独的模块上把负责通讯的机制放里面，比如说都是基于HTTP的服务或者是基于REST的服务，这样大家通过很简单的方式就可以实现通讯，就不会有很重的管道概念存在。

趋势四 

分散管理这很容易了解，我们左侧一群人，他们都要访问底层数据，这些胖的数据都放在一起，所以需要通过统一的方式来访问。而右侧大家可以拆解开，不同的服务访问不同的数据库，不同的数据文件，因而能够实现很好的效果。实际上我们用微服务也很容易，因为微服务带来另外一个现象，就是我们现在的数据库也在拆解，比如基于图的数据库，基于文档的数据库，基于KeyValue数据库。他们分别适用于不同的场景，所以我们完全可以通过一种微服务的方式把大家拆解开，不同的服务只访问自己的数据，上面再搭一层kafka把大家连到一起。

 

 

趋势五 

部署自动化现在我们开发完一个程序以后，如果用Docker我们可以持续在系统上不断的部署上去。Docker不仅提供了一整套工具来做，而且可以同时运行很多的实例，我们可以实现这些实例的部分升级，这也是我们持续部署自动化的一个概念。

 

趋势六 

为失败设计这个是非常好玩的，假设我们只有10台机器，每台机器的成功率是99%，那么加在一起成功率就是90%，但如果有100台服务机器，我们成功率就变成了0.37，所以失败一定会出现。0.99^10=0.900.99^100=0.37因此很多人为了保证系统的健壮，会制造出很多虚拟坏人把机器全部破坏，看你的鲁棒性。因此我们在设计的时候一定会想如果这个东西崩溃掉怎么办，因此很多时候无状态服务也成为一个流行的趋势。趋势七  进化的设计

在微服务里面我们可以不断的优化我们的结构，因为它们之间相互独立，所以大家可以做一种基于进化的设计方式。

 

那我们再做一个简单的比较，到底胖服务和微服务之间有什么优点和缺点呢？

 

1. 开发来说，胖服务更简单。因为在开发时虽然微服务看起来架构简单，但需要处理通讯，沟通，数据一致性等很多问题，所以其实开发更难，这也是为什么绝大多数人首先用的都是胖服务而不是微服务。

2. 持续部署上，微服务有很大的优势，因为它能够一个模块一个模块单独升级，而不需要升级全部。

3. 数据一致性来说，必然是胖服务好。因为胖服务的数据在一起，所以大家通过统一的管道来访问，因此数据不容易出问题。在微服务里面，数据往往存在多个副本，会有多个访问源，那我们就会出现各种冲突或者写之类的问题。

4. 微服务的数据可用性很高。因为大家独立保存自己的一份，或者服务之间各种互相替换，很多情况下数据即使出现一些小故障也能够带伤运行，如同人体一样。

5. 对于重构来说，实际上胖服务更容易重构。为什么呢？因为微服务中每个启动的服务相对固定，内部是包容在一起的，因此要想进行大的调整，会发现这个服务需要全部调整。对于胖服务来说，只要可能调整内部就行，对于外部往往是透明的。

6. 维护上来看，微服务会更方便。因为模块升级，修改等只管自己就可以，不用管其他。

7. 哪个服务支持更多的平台呢？答案还是微服务。因为能够支持不同语言，每个平台都是相互独立的，中间有个统一的交流语言就好。

 

说了这么多，我们应该用微服务吗？实际上微服务和胖服务很像一个中心控制的集权式国家以及自由浪漫的经济主义，他们并不是好与不好。从国家的创建来说，实际从国家的创立的初期，往往需要一个集权的力量控制所有，这就是胖服务；当国家建立起来以后，长期发展经济上行就需要微服务来帮助大家有活性，能够成长起来。所以早期经常用胖服务，晚期经常用微服务。当然，很多就希望一个完美的方案，是不是微服务能够解决所有问题呢？一开始用微服务就行了吗？这其实是一个幻想，大家不要想这么多，还是老老实实从胖服务做起。所以我们经常会说，仰望星空，脚踏实地。碰到任何一个设计，千万不要认为它是万能药，可以解决所有问题。出现big data，出现function program这类词之后，我们往往都会产生各种各样的想法，但最终都幻灭。

做一个总结：

• Microservices是一群通过HTTP沟通的独立自治的需求模块

• 迷信Microservices是痛苦的源泉

• 仰望星空，脚踏实地

 

资料：

视频 Microservices • Martin Fowler

博客http://martinfowler.com/articles/microservices.html