| 导读 | 微服务架构是一项在云中部署应用和服务的新技术。大部分围绕微服务的争论都集中在容器或其余技术是否能很好的实施微服务，而红帽说API应该是重点。 |
对微服务架构的理解linux
微服务架构数据库
微服务架构，主要是多了个 “微”。亚马逊有个粗粗的定义：一个微服务应用工程的全部开发、测试、运维加起来大约 6 到 8 我的，只须要两个披萨就能够聚餐了。缓存
反例：不是一个 Service 类组成的应用工程，发布成服务就是微服务。这样分的过小，理解微服务就很片面。杭州某金融大厂，曾经分的很细，形成了运维测试成本巨大。开始分了合，折腾…架构
为啥须要微服务？负载均衡
由 SOA 架构 -> 微服务架构的转变，得理解为何微服务架构被普遍提到并实践。它解决了什么问题，带来了什么价值？运维
传统企业或者不少企业的软件，大多不止一套系统，都是各个独立大系统的堆砌。总体存在的问题是：分布式
扩展性差ide
可靠性不高微服务
维护成本还很大组件化
重复轮子不少
那么这些问题，能够想到的解决方案就是：
组件化
服务化
微服务架构，将各个组件或者模块分散到各个服务中，对整个系统实现解耦。那微服务架构强调的重中之重就是业务系统须要完善的组件化和服务化。什么是组件化？
组件化，即将一个大系统，按照必定的业务或者技术维度关注形式，拆分红独立的组件。目的是为了分而治之，为了可重用，为了减小耦合度。好比按照技术维度：搜索组件、缓存组件；按照业务维度：用户中心、支付中心等
组件化是否是有点中台的意思？阿里巴巴提出 大中台，小前台；就是把组件化、插件化、服务化解决方案到极致。经过产品线公共业务或者技术下沉，造成各类技术或者业务中台
服务化前的问题
没有服务化，不表明不是分布式或集群
分布式，就是多个实例提供相同的服务。好比多个地方动车站里面，多个机器提供取票服务。多个地方，北京上海等，就是多机房，多个取票服务一块儿组成了集群，造成分布式服务。那啥是服务化？
服务化，强调 “化”！核心就是不一样服务之间的通讯。是一种以服务为中心的解决方案：
服务注册
服务发布
服务调用
服务监控
服务负载均衡
没有服务化的架构问题
没有服务化前，举个例子，会更形象：
假设有个取票服务、买票服务、改座服务都须要验证下用户身份真实性，那么会存在下面的问题：
取票服务 -> 调用用户DB代码 -> 用户DB
买票服务 -> 调用用户DB代码 -> 用户DB
改座服务 -> 调用用户DB代码 -> 用户DB
明显的问题是：
代码重复：不一样业务相同访问 DB 的 userDAO 代码逻辑。并且每一个服务这块代码是不一样人维护的。
可维护性低：不一样人维护；不一样地方维护；每次 DB 字段改变或者迁库，所有业务都有修改
DB 访问耦合
天然也有解决方案是：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 之间相互调用。服务化明显改变：
DB 隔离：这样底层细节设计能够屏蔽，后续加上其余存储 Cache 等对业务调用方无感知。
经过 Service 之间通讯：具体协议能够 RPC / HTTP 等
服务化后的好处：
调用简单：不用写相同的访问用户服务代码，调用一个服务便可
代码复用：跟 lib 形式的代码复用有所区别在于，服务化经过通讯的方式解决
业务隔离
数据库解耦
不能否认的微服务架构或者服务化带来新的问题
一、自己不大的系统，业务不复杂的系统也不须要微服务架构。微服务架构会带来必定的复杂性，是一套完整的服务治理方案
二、多个模块数据库，分布式事务是一个挑战
三、开发过程，增长了测试等必定的复杂性
有利必有弊，具体场景具体选择
小结
本小结，不是讲how，讲的是 why。只有懂 why ，才能更好地 do。从为啥服务化？到为啥微服务架构这么流行：
微服务扩展性高
微服务可靠性高
微服务 维护成本小
微服务几乎没有重复轮子
微服务直接调用调用简单
微服务业务隔离
微服务数据库解耦Linux就该这么学