微服务有啥作用？
Posted
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了微服务有啥作用？相关的知识，希望对你有一定的参考价值。
万能的百度网友帮忙解决一下问题啊！非常感谢！
维基上对微服务的定义为：一种软件开发技术- 面向服务的体系结构（SOA）架构样式的一种变体，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。微服务的最重要的单一特征可能是，由于服务较小且可独立部署，因此不再需要繁琐的行动才能更改应用程序中的一行文字。
在微服务模型中，组件是独立部署的，并通过REST，事件流和消息代理的某种组合进行通信-因此，可以针对该服务优化每个单独服务的堆栈。技术一直在变化，由多个较小的服务组成的应用程序随着更理想的技术的发展而变得更容易且成本更低。
使用微服务，可以单独部署单个服务，但是也可以单独扩展它们。由此带来的好处是显而易见的：如果正确完成，微服务比单片应用程序所需的基础结构要少，因为微服务仅支持对需要它的组件进行精确缩放，而对于单片应用程序则不需要整个应用程序。
比如像HC服务网格是基于Istio及容器技术的微服务治理平台，以无侵入方式为多语言、不同部署形态的异构应用提供服务治理、服务监控和安全控制等微服务管理能力。能够将服务通信、观测与安全能力下沉到基础设施层，降低分布式应用开发复杂度，为应用运维减负，推动企业应用整体向服务治理平台迁移，提升IT系统的整体承载能力、高可用能力。 参考技术A （1）服务的独立部署，每个服务都是独立的项目，可以独立部署，不依赖于其他服务，耦合性低。
（2）服务的快速启动，拆分之后服务启动的速度要比拆分之前快很多，因为依赖的库少了，代码量也少了。
（3）更加适合敏捷开发。敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行。服务拆分可以快速发布新版本，修改哪个服务只需要发布对应的服务即可，不用整体重新发布。
（4）职责专一，由专门的团队负责专门的服务。业务发展迅速时，研发人员也会越来越多，每个团队可以负责对应的业务线，服务的拆分有利于团队之间的分工。
（5）服务可以动态按需扩容，当某个服务的访问量较大时，我们只需要将这个服务扩容即可。
（6）代码的复用，每个服务都提供REST API，所有的基础服务都必须抽出来，很多的底层实现都可以以接口方式提供。想要了解更多，我推荐你去看看时速云，他们是一家全栈云原生技术服务提供商，提供云原生应用及数据平台产品，其中涵盖容器云PaaS、DevOps、微服务治理、服务网格、API网关等。大家可以去体验一下。
希望能给您提供帮助，可以给个大大的赞不。 参考技术B 微服务是国内领先的基于微信公众平台的营销工具，致力于提供全方面的微信运营服务，微信代运营，线下活动推广服务，真正实现客户的一站式服务。[1]
该平台开发了为商家定制的“个性化管理、营销推广、客户关系管理、会员卡管理”等几个重要的运营管理模块，涵盖了微信管家、微信应用解决方案、微信客服客户端、人工微信客服四部分。
服务方式的飞跃
以微信为载体的服务平台，注重增加用户粘性，增强服务过程的趣味性，维系老客户关系，体现企业的服务创新。
用户体验升级
二维码扫一扫，随时随地享受文字、图片、视频等多种信息传输方式，满足客户多元化需求。
微时代资源共享
微时代来临，3亿微信用户商机无限。
个性化服务升级
脑筋急转弯、猜谜语、猜歌名，多样化的微互动营销活动不仅可以增加用户体验，还可以促成用户下单。
服务成本可控
按服务量收费，无需考虑坐席空闲。成本，每一分钱都花在刀刃上。
DDD为什么能火起来？和微服务有啥关系？
作者：等不到的口琴
链接：www.cnblogs.com/Courage129/p/14839544.html
DDD为什么能火起来？我们先不讨论DDD的定义， 先梳理一下DDD火起来的背景， 根据我学习的套路， 永远是为什么为先，再是解决什么问题，是什么东西， 最后如何使用。
我们都知道这些年随着设备以及技术的发展，软件架构发生了很多变化，从最初的单机(BS/CS)架构到后面的集中式架构，再到如今的微服务架构， 现在基本可以说是微服务架构盛行的时代， DDD早在2004年就由埃里克·埃文斯提出， 但一直处于一个不愠不火的状态，直到Martin Fowler的《Microservices》引起大家注意， 也就是微服务盛行之后(这儿需要说明的是，微服务最早的提出者不是Martin Fowler，而是Fred George)， DDD再次回到人们视野中间，为什么呢 ？
我们先看一下三种技术架构的演进以及主要区别：
第一阶段是单机架构，特征是整个开发围绕着数据库进行设计和开发。
第二个阶段是三层式的集中式架构，采用面向对象的设计方法，业务逻辑分业务层、逻辑层、数据访问层，这种架构很容易某一层或者几层变得臃肿，扩展性较差， 另外摩尔定律失效， 单台机器性能有限。
第三层阶段是微服务架构，在集中式架构中， 系统分析、设计和开发往往是独立进行的，而且各个阶段负责人可能不一样，那么就涉及到交流信息丢失的问题， 另外项目从分析到开发经历的流程很长，很容易最终开发设计与需求实现的不一样，微服务主要就是解决第二阶段的这些痛点，实现应用之间的解耦，解决单体应用扩展性的问题。微服务存在的问题进入微服务之后 ， 解决了集中式架构的单体应用很多问题， 但是新的问题应运而生 ， 微服务的粒度应该多大 ？微服务如何设计呢？微服务如何拆分 ？微服务边界在哪里 ？
很长时间人们都没有解决这一问题，就连Martin Fowler在提出微服务架构的时候也没有告诉我们这该如何拆分微服务。
甚至在很长的时间里人们对微服务拆分产生了一些误解， 有人认为："微服务很简单，就是将之前的单体应用拆分成多个部署包， 或者将原来的单体应用架构替换为一套支持微服务的技术架构，就算是微服务了。" 还有人认为微服务应该拆分得越小越好。
鉴于上述情形， 很多项目因为前期拆分过度， 导致复杂度过高， 导致后期难以运维甚至难以上线。另外，微服务系列面试题和答案全部整理好了，微信搜索互联网架构师，在后台发送：2T，可以在线阅读。
可以得出一个结论：微服务拆分困境产生的根本原因就是不知道业务或者微服务的边界到底在什么地方。换句话说，确定了业务边界和应用边界，这个困境也就迎刃而解了。而DDD就是解决了这个确定业务边界的问题，可见DDD并不是一种技术架构，而是一种划分业务领域范围的方法论。DDD的兴起是由于很多熟悉领域驱动建模(DDD)的工程师在进行微服务设计时， 发现用DDD的思路进行业务梳理可以很好规划服务边界， 可以很好实现微服务内部和外部的"高内聚、低耦合"。于是越来越多的人将DDD作为业务划分的指导思想。那么，什么是DDD呢？
DDD概述通过上文的学习就可以知道DDD是一种拆解业务、划分业务、确定业务边界的方法， 是一种高度复杂的领域设计思想，将我们的问题拆分成一个个的域， 试图分离技术实现的复杂性，主要解决的是软件难以理解难以演进的问题，DDD不是一种架构， 而是一种架构方法论， 目的就是将复杂问题领域简单化， 帮助我们设计出清晰的领域和边界， 可以很好的实现技术架构的演进。DDD包括两部分，战略设计部分 和 战术设计部分战略设计主要从业务视角出发，建立业务领域模型，划分领域边界，建立通用语言的限界上下文，限界上下文可以作为微服务设计的参考边界。战术设计则从技术视角出发，侧重于领域模型的技术实现，完成软件开发和落地，包括：聚合根、实体、值对象、领域服务、应用服务和资源库等代码逻辑的设计和实现。
DDD战略设计会建立领域模型， 这四个字放一起会让人觉得很高深， 其实是纸老虎， 通俗来说就是模拟某个领域的的一种模型， 这个模型比较抽象， 但便于人们交流， 举个例子：公园有一棵桃树， 如果我们想好好研究桃树该怎么研究 ？桃子好吃吗？贵不贵？品种？怎么种植？种在什么地方 ？做成桃木剑？桃子树叶药用价值？
你看， 这样研究每一个问题都很有道理， 但是又很混乱，再回忆一下初中生物书上是这么研究的？，微信搜索公众号互联网架构师，在后台发送：2T，送你一份惊喜礼包。
先将植物根据大家的理解分成多个器官组成， 像桃子、桃叶、桃花等等， 然后将每一个器官再根据功能细分成组织， 再根据这个组织中各个细胞的形态等作用分成不同的细胞， 你看看这是不是一种很有条理的分析方法。
DDD也是如此， 当我们面对桃树这种复杂的业务的时候，先根据固有的认识分成多个器官(领域)，然后再在每一个领域中根据某些维度(这儿是功能)分为多个组织(聚合)， 而每一个组织中由很多细胞(实体)组成，这就是一种战略， 有哪些好处呢 ？
可以确保我们讨论的边界， 也就是讨论的东西是一个领域一个维度的， 对于桃树来说， 桃子 、桃花、桃叶、树干都是不同的领域， 划分不同领域的就是边界， 我们这儿叫领域边界， 当我们确定好这些领域之后， 就可以确保我们讨论的是同一个领域部分的东西，这样的好处就是我们可以规定好一些概念， 或者说术语， 以后大家讨论的时候就尽可能少的信息丢失。
DDD战略设计会建立领域模型 ， 领域模型用来指导微服务的设计和拆分， DDD第一步要做的就是来一个头脑风暴， 可以理解成一起讨论对业务的理解 ， 主要目的就是尽可能前面不遗漏的分解我们的业务领域， 就好比刚刚的桃树， 最先要做的就是尽可能多的分析， 确保每一个领域都可以被关注到。
相关阅读：2T架构师学习资料干货分享
在实践中 ，往往会采用用例分析、场景分析和用户旅程分析， 这是一个发散的过程，头脑风暴阶段会产生很多实体、命令、事件等领域对象， 我们从不同的维度对进行聚类形成聚合、限界上下文等边界，建立领域模型， 这是一个收敛的过程。
具体来说， 我们可以通过三步来确定领域模型和微服务边界。
第一步：在事件风暴中梳理业务过程中的用户操作、事件以及外部依赖关系等，根据这些要素梳理出领域实体等领域对象。
第二步：根据领域实体之间的业务关联性，将业务紧密相关的实体进行组合形成聚合，同时确定聚合中的聚合根、值对象和实体。在这个图里，聚合之间的边界是第一层边界，它们在同一个微服务实例中运行，这个边界是逻辑边界，所以用虚线表示。微信搜索公众号互联网架构师，在后台发送：2T，送你一份惊喜礼包。
第三步：根据业务及语义边界等因素，将一个或者多个聚合划定在一个限界上下文内，形成领域模型。在这个图里，限界上下文之间的边界是第二层边界，这一层边界可能就是未来微服务的边界，不同限界上下文内的领域逻辑被隔离在不同的微服务实例中运行，物理上相互隔离，所以是物理边界，边界之间用实线来表示。
上面除了领域、聚合、实体外还出现了聚合根、值对象等词语， 除此之外还有统一建模语言、子域、核心域、通用域、支撑域等， 其实都是纸老虎， 前面说过了为了方便对于某个领域的讨论往往会形成一些概念，这些概念会有一些名词概括， 上面的名词就是这么来的， 这就叫统一建模语言 ， 哈哈哈 ，好了，不扯淡, 我后面的文章会解释下这些词语的意思， 这儿主要讨论DDD解决什么了问题。
梳理一下DDD与微服务的关系， DDD 是一种架构设计方法，微服务是一种架构风格，两者从本质上都是为了追求高响应力，而从业务视角去分离应用系统建设复杂度的手段。两者都强调从业务出发，其核心要义是强调根据业务发展，合理划分领域边界，持续调整现有架构，优化现有代码，以保持架构 和代码的生命力，也就是我们常说的演进式架构。DDD 主要关注：从业务领域视角划分领域边界，构建通用语言进行高效沟通，通过业务抽象，建立领域模型，维持业务和代码的逻辑一致性。微服务主要关
注：运行时的进程间通信、容错和故障隔离，实现去中心化数据管理和去中心化服务治理，关注微服务的独立开发、测试、构建和部署。总结这篇文章主要研讨了DDD火起来的原因， 解决了什么业界难题， 知道DDD主要思路 ， 以及DDD大概的实现步骤等 。留个小问题：单体应用适合DDD吗？以上是关于微服务有啥作用？的主要内容，如果未能解决你的问题，请参考以下文章