史诗级鸿篇巨著微服务架构之微服务介绍

微服务架构认知

欢迎大家和小编一起探讨学习史诗级鸿篇巨著，微服务架构第一章——微服务架构介绍，在本文中主要和大家介绍一下微服务架构的理念，让大家对微服务有个比较直观的认识，在介绍本次微服务系列之前，先来给大家做个剧透，看看我们整篇系列文章要介绍的内容。

1. 微服务介绍
2. SpringCloud

在微服务的整个体系当中，它包含了许许多多的组件，比如：

• 服务治理——Eureka、Nacos、Consul
• 负载均衡——Ribbon
• 服务容错——Hystrix
• 服务调用——Feign、DubboRPC
• 分布式配置中心——Config、Nacos
• 消息总线——Bus
• 服务网关——Gateway
• 调用链追踪——Sleuth
• 消息驱动——Stream
• 流量防控——Sentinel

看到这里，很多小伙伴们是不是已经跃跃欲试了呢？
他们到底是何方神圣、在这里到底有什么不为人知的奥秘？
别着急，请听我一一道来。

别忘了点赞、关注加收藏，也算是对小编最大的鼓励了~

如何权衡微服务的利弊

我们先来思考一下这样一个问题：
我们所说的每一个不同的技术栈、每一个不同的服务，它们有优点也有缺点，这里我们探讨一下你的应用系统是否适合微服务架构，我们要从哪些方面衡量微服务的利与弊？

微服务的优点

我们先来介绍一下微服务的优点。
首先它显而易见的优点就是可以快速响应变更，这得益于微服务架构遵循了单一职责的架构理念，你的每一块微服务都划定了自身的势力范围，再也不会像以前的单体应用一样，你改造一个小小的地方就能牵一发而动全身的效果，微服务架构天然的适用于小步快跑的开发节奏，同时，每一块微服务都是可以独立部署的，这样就不必受制于单体单体应用的发布节奏等限制条件，基于这些特点，我们可以说微服务架构特别适用于当前互联网公司这种超快猛的开发节奏模式。

除了这个以外，微服务还特别易于拓展，微服务与微服务直接有相对比较清晰的边界，并且它不会过度的受制于技术栈，比如你之前是个单体应用，那么这个单体应用作为一个整体，它使用哪种技术栈或者底层应该使用哪些中间件都应该从整个应用的级别来进行考量，而我们使用了微服务架构以后，你的开发团队在当前微服务技术栈上面会有更多的话语权。

比如说我的商品中心服务可以使用Hystrix作为降级熔断的组件，而订单服务想要使用Sentinel作为降级组件也是没有问题的，尽管如此，咱们这里还是强调——不过度受制于技术栈，但并不是让大家天马行空，想用什么就用什么。比如说你的一个服务使用Eureka作为服务发现机制，而另一个服务则使用Nacos作为服务发现框架，那么这直接可能也会产生不兼容，所以说微服务架构可以保证技术栈相对统一的前提下，给到各个微服务组件最大的自由度。

除了这些，微服务架构还可以做到对你的业务进行更精细度的控制，比如说咱们可以把一段特殊的降级熔断逻辑应用在某个特定的微服务上，为不同的方法调用制定合理的超时策略以及重试策略
除此以外，我们还可以做到更精粒度控制局部限流，提高资源利用率。
最后我们从业务架构的领域来说，微服务是一种更加面向业务的架构模式，我们的传统应用在业务模型领域非常的杂乱，它往往是直接访问数据库，获取第一手数据，但是在微服务架构这里，我们不再依赖于底层的数据模型，而是面向业务和领域模型，你的数据模型只会存在于当前的微服务领域当中，并不会共享给其他的服务，比方说我们构建了一个电商系统的商品中心，那么商品的元数据它所存放的数据库表并不会由其他的微服务直接访问，它们只能通过我的商品中心所暴露出来的接口获取到业务对象，这样我对底层的物理数据模型进行更改再也不会影响到其他的业务方，而且这种业务和领域驱动的方式非常易于抽象，比如阿里集团在几年前开始推进的大中台战略，就是电商场景链路中的公共领域模型抽象成了一系列的中台服务，比方说淘系订单、淘系商品、营销优惠等等，他们被抽象成了中台的服务业务以后，所有不同的事业部、业务方对接到他们的系统以后就可以坐享其成。所以阿里集团得益于他的大中台战略，大大缩减了不同事业部开发新项目从研发到落地时间周期和成本。

微服务的缺点

说完优点后，我们再来看看微服务都有哪些显而易见的缺点。
第一个缺点就是我们不得不说的——部署结构非常复杂。为什么呢？ 一来就是他的业务模块众多，我们以前的单体应用尽管它是分布式的部署结构，可是它部署的内容都是一模一样的，而微服务架构却不同，每个不同的微服务它部署的内容都是千差万别，甚至它每一个模块所依赖的组件和中间件都是不同的，并且微服务架构它天生的就会引入一些额外的组件，这样一来，你的部署结构就会变得复杂，同时，运维成本也会相应增加。除此以外微服务它还考验着你公司的整体实力，因为它非常依赖于平台的支撑，所谓平台就是它支撑微服务的组件。比如说，服务治理它就需要一个注册中心；还有这么多不同微服务的配置，如果想统一管理，还需要一个配置中心；除此以外，你的调用链路分析、网关层可能统统都需要依赖于微服务的组件来完成。并且我们可能还需要投入更多的研发成本。
毕竟微服务架构所采用的技术栈他所用的技术要求是远高于单体应用的，不仅需要资深的研发人员，而且将单体应用改造成微服务架构也是一笔不小的研发成本支出。那我们从技术的角度考虑，还有一个分布式的问题，这里就牵扯到一个绕不开的话题——一致性，比方说作为一个单体的分布式应用，从一个下单请求开始到结束它的整条链路可以轻轻松松的包含在一个事务里来完成，但是在微服务的架构下，你不得不串联调用上下游很多微服务共同完成一个事务，如何保证事务的一致性？ 是强一致性？ 弱一致性？还是最终一致性？ 在这之间你如何做选择？如果采用了最终一致性方案，你还要考虑好如何做异常补偿。

最后一个缺点我们就要说到拆分的水平了，微服务架构的拆分强依赖与你当前的业务，如果你的架构师对你当前的业务理解不到位，导致微服务拆分的力度过粗或者过细，那微服务的优越性就会大大折扣，甚至王者直接变青铜，所以说采用微服务架构，不仅是对技术实力的一种考验，同时也考验着架构师团队对公司业务的理解与把控

到底合适不合适？

我们既然说了微服务的有点，也说了微服务的缺点，那么我们的系统到底适不适合微服务架构呢？
这个问题还不简单？微服务听起来多么高大上的名词啊，而且大家现在都在使用啊，我从网上搜出一大堆优点给领导这么一说，大老板一听这么多优点，一拍桌子：“上！”。不管三七二十一，也不管什么业务，领导说上咱就上。

先来看一下下面两个图中的对比：

这个图中，虽然是包含了多个模块，但是它并不是微服务架构哦~
没错，它是一个单体应用，我们在开发层次对不同的模块进行了划分，一定程度上减少了耦合，虽然是单体应用，但这并不意味着业务简单，它是一个很典型电商系统，里面牵扯了各种各样电商业务中的基本交易流程，包括用户的关系等等。

再看一下下面的图：

上面这个图里的项目是小编曾接手过的一个微服务架构的项目，不说别的，Nacos、Sentinel、DubboRPC前沿的技术应有尽有，从图中也能看出来服务模块众多、技术五花八门，但是这只是一个工作流程审核系统，微服务的引用着实也是徒增了很多开发难度和维护成本。

这种情况就成了“为了微服务而为服务”，但是微服务并不是包治百病的良药，脱离了对自身业务的理解，一切的架构都是脱离实际的，我们在决定要不要做微服务、怎么样做微服务的拆分，都要去紧密的结合自己的业务。那我们从业务角度出发，最简单的方法论其实只有两条，第一条就是——业务规模，如果公司一开始就使用单体应用的架构模式，直到他的业务规模达到非常之大了，打个比方，小编了解有一家很著名的公司叫SuccessFactors，它的人力资源软件在全球排行第二，仅次于WorkDay，尽管它具有如此大的规模，但是它到今天依然是采用的单体架构的模式，那到了这个阶段真的是——Too big to change；这种情况说的其实也是一种极端，那么我们不妨走到另一个极端上，就是刚刚开始搭建应用的时候——At very first beginning，在这个阶段如果应用微服务它的成本是最低的，所以呢这是一个博弈的过程，你的应用所处的规模应该在这两个极端的某一个点上，我们要衡量改造微服务所带来的成本增加，与它预期所能达到的收益，在这之前做一个博弈。

除了从业务规模考虑以外，我们还要深刻理解自己的业务，理解它的业务架构，这里所说的业务架构并不是在技术层面，而是从业务层面理解整个系统的业务模式、业务流、用户用例以及未来的业务规划，这样我们才可以抽象出更合理的业务领域模型，从而更合理的对微服务拆分的粒度进行把控。从这个角度来说，咱们的业务规模，也就是成本和收益的博弈过程决定了我们是不是应该要去做微服务改造，而我们对业务架构以及领域模型的理解决定了怎么做微服务，如何来拆分，拆分成多细的粒度。