微服务架构,这 5 年左右一直被承认,是软件架构的将来方向。须要你们理解的是,为何须要服务化。好比微服务架构对企业来讲,带来什么价值?有啥弊端?html
这里浅谈一下微服务架构,主要仍是在理解 Why :为何须要服务化?程序员
微服务架构,主要是多了个 “微”。亚马逊有个粗粗的定义:一个微服务应用工程的全部开发、测试、运维加起来大约 6 到 8 我的,只须要两个披萨就能够聚餐了。数据库
反例:不是一个 Service 类组成的应用工程,发布成服务就是微服务。这样分的过小,理解微服务就很片面。杭州某金融大厂,曾经分的很细,形成了运维测试成本巨大。开始分了合,折腾...缓存
由 SOA 架构 -> 微服务架构的转变,得理解为何微服务架构被普遍提到并实践。它解决了什么问题,带来了什么价值?架构
传统企业或者不少企业的软件,大多不止一套系统,都是各个独立大系统的堆砌。总体存在的问题是:负载均衡
那么这些问题,能够想到的解决方案就是:运维
微服务架构,将各个组件或者模块分散到各个服务中,对整个系统实现解耦。那微服务架构强调的重中之重就是业务系统须要完善的组件化和服务化。什么是组件化?socket
组件化,即将一个大系统,按照必定的业务或者技术维度关注形式,拆分红独立的组件。目的是为了分而治之,为了可重用,为了减小耦合度。好比按照技术维度:搜索组件、缓存组件;按照业务维度:用户中心、支付中心等分布式
组件化是否是有点中台的意思?阿里巴巴提出 大中台,小前台;就是把组件化、插件化、服务化解决方案到极致。经过产品线公共业务或者技术下沉,造成各类技术或者业务中台ide
(图来自漫画程序员小灰)
分布式,就是多个实例提供相同的服务。好比多个地方动车站里面,多个机器提供取票服务。多个地方,北京上海等,就是多机房,多个取票服务一块儿组成了集群,造成分布式服务。那啥是服务化?
服务化,强调 “化”!核心就是不一样服务之间的通讯。是一种以服务为中心的解决方案:
没有服务化前,举个例子,会更形象:
假设有个取票服务、买票服务、改座服务都须要验证下用户身份真实性,那么会存在下面的问题:
明显的问题是:
天然也有解决方案是:lib。维护一个 user-DAO-lib 1.0.0 release 包,给各个业务方。
解决了问题,引入了新的问题,lib 升级是巨大而又漫长的问题。好比小李是维护 user-DAO-lib 的人,有一次写了隐蔽的 bug 。user-lib 升级到了 1.0.1 release,花了 1 个月左右时间,推几十个业务方升级完毕。而后这个 bug 运行了几天出现了,考虑升级fix或者回滚都是巨大的成本
基于服务化,就能够完美解决问题。
如图 Post 文章服务调用 Video 视频服务,须要经过最上层的 Service 之间相互调用。服务化明显改变:
服务化后的好处:
一、自己不大的系统,业务不复杂的系统也不须要微服务架构。微服务架构会带来必定的复杂性,是一套完整的服务治理方案 二、多个模块数据库,分布式事务是一个挑战 三、开发过程,增长了测试等必定的复杂性
有利必有弊,具体场景具体选择
本小结,不是讲how,讲的是 why。只有懂 why ,才能更好地 do。从为啥服务化?到为啥微服务架构这么流行:
参考资料