微服务架构一直火为什么要服务化.docx

微服务架构一直火为什么要服务化.docx

《微服务架构一直火为什么要服务化.docx》由会员分享，可在线阅读，更多相关《微服务架构一直火为什么要服务化.docx（8页珍藏版）》请在冰豆网上搜索。

微服务架构一直火为什么要服务化

微服务架构一直火，为什么服务化要搞懂

微服务架构，这5年左右一直被认可，是软件架构的未来方向。

需要大家理解的是，为什么需要服务化。

比如微服务架构对企业来说，带来什么价值？

有啥弊端？

这里浅谈一下微服务架构，主要还是在理解Why：

为什么需要服务化？

一、对微服务架构的理解

1.1微服务架构

微服务架构，主要是多了个“微”。

亚马逊有个粗粗的定义：

一个微服务应用工程的所有开发、测试、运维加起来大约6到8个人，只需要两个披萨就可以聚餐了。

反例：

不是一个Service类组成的应用工程，发布成服务就是微服务。

这样分的太小，理解微服务就很片面。

杭州某金融大厂，曾经分的很细，造成了运维测试成本巨大。

开始分了合，折腾...

1.2为啥需要微服务？

由SOA架构->微服务架构的转变，得理解为什么微服务架构被广泛提到并实践。

它解决了什么问题，带来了什么价值？

传统企业或者很多企业的软件，大多不止一套系统，都是各个独立大系统的堆砌。

整体存在的问题是：

·扩展性差

·可靠性不高

·维护成本还很大

·重复轮子很多

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

·组件化

·服务化

微服务架构，将各个组件或者模块分散到各个服务中，对整个系统实现解耦。

那微服务架构强调的重中之重就是业务系统需要完善的组件化和服务化。

什么是组件化？

组件化，即将一个大系统，按照一定的业务或者技术维度关注形式，拆分成独立的组件。

目的是为了分而治之，为了可重用，为了减少耦合度。

比如按照技术维度：

搜索组件、缓存组件；按照业务维度：

用户中心、支付中心等

组件化是不是有点中台的意思？

阿里巴巴提出大中台，小前台；就是把组件化、插件化、服务化解决方案到极致。

通过产品线公共业务或者技术下沉，形成各种技术或者业务中台

二、服务化前的问题

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

分布式，就是多个实例提供相同的服务。

比如多个地方动车站里面，多个机器提供取票服务。

多个地方，北京上海等，就是多机房，多个取票服务一起组成了集群，形成分布式服务。

那啥是服务化？