微服务架构最强讲解，那叫⼀个通俗易懂
⼀、微服务架构介绍
微服务架构（Microservice Architecture）是⼀种架构概念，旨在通过将功能分解到各个离散的服务中以实现对解决⽅案的解耦。你可以将其看作是在架构层次⽽⾮获取服务的
类上应⽤很多SOLID原则。微服务架构是个很有趣的概念，它的主要作⽤是将功能分解到离散的各个服务当中，从⽽降低系统的耦合性，并提供更加灵活的服务⽀持。
概念： 把⼀个⼤型的单个应⽤程序和服务拆分为数个甚⾄数⼗个的⽀持微服务，它可扩展单个组件⽽不是整个的应⽤程序堆栈，从⽽满⾜服务等级协议。
定义： 围绕业务领域组件来创建应⽤，这些应⽤可独⽴地进⾏开发、管理和迭代。在分散的组件中使⽤云架构和平台式部署、管理和服务功能，使产品交付变得更加简单。
本质： ⽤⼀些功能⽐较明确、业务⽐较精练的服务去解决更⼤、更实际的问题。
⼆、出现和发展
微服务（Microservice）这个概念是2012年出现的，作为加快Web和移动应⽤程序开发进程的⼀种⽅法，2014年开始受到各⽅的关注，⽽2015年，可以说是微服务的元年；
越来越多的论坛、社区、blog以及互联⽹⾏业巨头开始对微服务进⾏讨论、实践，可以说这样更近⼀步推动了微服务的发展和创新。⽽微服务的流⾏，Martin Fowler功不可没。
这⽼头是个奇⼈，特别擅长抽象归纳和制造概念。特别是微服务这种新⽣的名词，都有⼀个特点：⼀解释就懂，⼀问就不知，⼀讨论就打架。
Martin Fowler是国际著名的OO专家，敏捷开发⽅法的创始⼈之⼀，现为ThoughtWorks公司的⾸席科学家。在⾯向对象分析设计、UML、模式、软件开发⽅法学、XP、重构等⽅⾯，都是世界顶级的专家，现为Thought Works公司的⾸席科学家。Thought Works是⼀家从事企业应⽤开发和——集成的公司。早在20世纪80年代，Fowler就是使⽤对象技术构建多层企业应⽤的倡导者，他著有⼏本经典书籍：《企业应⽤架构模式》、《UML精粹》和《重构》等。
———— 百度百科
三、传统开发模式和微服务的区别
先来看看传统的web开发⽅式，通过对⽐⽐较容易理解什么是Microservice Architecture。和Microservi
分布式和微服务的关系ce相对应的，这种⽅式⼀般被称为Monolithic（单体式开发）。
所有的功能打包在⼀个 WAR包⾥，基本没有外部依赖（除了容器），部署在⼀个JEE容器（Tomcat，JBoss，WebLogic）⾥，包含了DO/DAO，Service，UI等所有逻辑。
优点：
①开发简单，集中式管理
②基本不会重复开发
③功能都在本地，没有分布式的管理和调⽤消耗
缺点：
1、效率低：开发都在同⼀个项⽬改代码，相互等待，冲突不断
2、维护难：代码功功能耦合在⼀起，新⼈不知道何从下⼿
3、不灵活：构建时间长，任何⼩修改都要重构整个项⽬，耗时
4、稳定性差：⼀个微⼩的问题，都可能导致整个应⽤挂掉
5、扩展性不够：⽆法满⾜⾼并发下的业务需求
常见的系统架构遵循的三个标准和业务驱动⼒：
1、提⾼敏捷性：及时响应业务需求，促进企业发展
2、提升⽤户体验：提升⽤户体验，减少⽤户流失
3、降低成本：降低增加产品、客户或业务⽅案的成本
基于微服务架构的设计：
⽬的： 有效的拆分应⽤，实现敏捷开发和部署
关于微服务的⼀个形象表达：
X轴： 运⾏多个负载均衡器之后的运⾏实例
Y轴： 将应⽤进⼀步分解为微服务（分库）
Z轴： ⼤数据量时，将服务分区（分表）
四、微服务的具体特征
官⽅的定义：
1、⼀些列的独⽴的服务共同组成系统
2、单独部署，跑在⾃⼰的进程中
3、每个服务为独⽴的业务开发
4、分布式管理
5、⾮常强调隔离性
⼤概的标准：
1、分布式服务组成的系统
2、按照业务，⽽不是技术来划分组织
3、做有⽣命的产品⽽不是项⽬
4、强服务个体和弱通信（ Smart endpoints and dumb pipes ）
5、⾃动化运维（ DevOps ）
6、⾼度容错性
7、快速演化和迭代
五、SOA和微服务的区别
1、SOA喜欢重⽤，微服务喜欢重写
SOA 的主要⽬的是为了企业各个系统更加容易地融合在⼀起。说到SOA不得不说ESB(EnterpriseService Bus)。ESB是什么? 可以把ESB想象成⼀个连接所有企业级服务的脚⼿架。通过service broker，它可以把不同数据格式或模型转成canonical格式，把XML的输⼊转成CSV传给legacy服务，把SOAP 1.1服务转成 SOAP 1.2等等。它还可以把⼀个服务路由到另⼀个服务上，也可以集中化管理业务逻辑，规则和验证等等。它还有⼀个重要功能是消息队列和事件驱动的消息传递，⽐如把JMS服务转化成SOAP协议。各服务间可能有复杂的依赖关系。
微服务 通常由重写⼀个模块开始。要把整个巨⽯型的应⽤重写是有很⼤的风险的，也不⼀定必要。我们向微服务迁移的时候通常从耦合度最低的模块或对扩展性要求最⾼的模块开始，把它们⼀个⼀个剥离出来⽤敏捷地重写，可以尝试最新的技术和语⾔和框架，然 后单独布署。它通常不依赖其他服务。微服务中常⽤的API Gateway的模式主要⽬的也不是重⽤代码，⽽是减少客户端和服务间的往来。API gateway模式不等同与Facade模式，我们可以使⽤如future之类的调⽤，甚⾄返回不完整数据。
2、SOA喜欢⽔平服务，微服务喜欢垂直服务
SOA 设计喜欢给服务分层(如Service Layers模式)。我们常常见到⼀个Entity服务层的设计，美其名⽈Data Access Layer。这种设计要求所有的服务都通过这个Entity服务层来获取数据。这种设计⾮常不灵活，⽐如每次数据层的改动都可能影响到所有业务层的服务。⽽每个微服务通常有它⾃⼰独⽴的data store。我们在拆分数据库时可以适当的做些去范式化(denormalization)，让它不需要依赖其他服务的数据。
微服务 通常是直接⾯对⽤户的，每个微服务通常直接为⽤户提供某个功能。类似的功能可能针对⼿机有⼀个服务，针对机顶盒是另外⼀个服务。在SOA设计模式中这种情况通常会⽤到Multi-ChannelEndpoint的模式返回⼀个⼤⽽全的结果兼顾到所有的客户端的需求。
3、SOA喜欢⾃上⽽下，微服务喜欢⾃下⽽上
SOA 架构在设计开始时会先定义好服务合同(service contract)。它喜欢集中管理所有的服务，包括集中管理业务逻辑，数据，流
程，schema，等等。它使⽤Enterprise Inventory和Service Composition等⽅法来集中管理服务。SOA架构通常会预先把每个模块服务接⼝都定义好。模块系统间的通讯必须遵守这些接⼝，各服务是针对他们的调⽤者。
SOA架构适⽤于TOGAF之类的架构⽅法论。
微服务 则敏捷得多。只要⽤户⽤得到，就先把这个服务挖出来。然后针对性的，快速确认业务需求，快速开发迭代。
六、怎么具体实践微服务
要实际的应⽤微服务，需要解决⼀下四点问题：
1、客户端如何访问这些服务
2、每个服务之间如何通信
3、如此多的服务，如何实现？
4、服务挂了，如何解决？（备份⽅案，应急处理机制）
1、客户端如何访问这些服务
原来的Monolithic⽅式开发，所有的服务都是本地的，UI可以直接调⽤，现在按功能拆分成独⽴的服务，跑在独⽴的⼀般都在独⽴的虚拟机上的 Java进程了。客户端UI如何访问他的？
后台有N个服务，前台就需要记住管理N个服务，⼀个服务下线/更新/升级，前台就要重新部署，这明显不服务我们 拆分的理念，特别当前台是移动应⽤的时候，通常业务变化的节奏更快。
另外，N个⼩服务的调⽤也是⼀个不⼩的⽹络开销。还有⼀般微服务在系统内部，通常是⽆ 状态的，⽤户登录信息和权限管理最好有⼀个统⼀的地⽅维护管理（OAuth）。
所以，⼀般在后台N个服务和UI之间⼀般会⼀个代理或者叫API Gateway，他的作⽤包括：
① 提供统⼀服务⼊⼝，让微服务对前台透明
② 聚合后台的服务，节省流量，提升性能
③ 提供安全，过滤，流控等API管理功能
其实这个API Gateway可以有很多⼴义的实现办法，可以是⼀个软硬⼀体的盒⼦，也可以是⼀个简单的MVC框架，甚⾄是⼀个Node.js的服务端。他们最重要的作 ⽤是为前台（通常是移动应⽤）提供后台服务的聚合，提供⼀个统⼀的服务出⼝，解除他们之间的耦合，不过API Gateway也有可能成为单点故障点或者性能的瓶颈。
⽤过Taobao Open Platform（淘宝开放平台）的就能很容易的体会，TAO就是这个API Gateway。
2、每个服务之间如何通信
所有的微服务都是独⽴的Java进程跑在独⽴的虚拟机上，所以服务间的通信就是IPC（inter process communication），已经有很多成熟的⽅案。现在基本最通⽤的有两种⽅式：
同步调⽤：
①REST（JAX-RS，Spring Boot）
②RPC（Thrift, Dubbo）
异步消息调⽤(Kafka, Notify, MetaQ)
同步和异步的区别：
⼀般同步调⽤⽐较简单，⼀致性强，但是容易出调⽤问题，性能体验上也会差些，特别是调⽤层次多的时候。RESTful和RPC的⽐较也是⼀个很有意 思的话题。
⼀般REST基于HTTP，更容易实现，更容易被接受，服务端实现技术也更灵活些，各个语⾔都能⽀持，同时能跨客户端，对客户端没有特殊的要求，只要封装了HTTP的SDK就能调⽤，所以相对使⽤的⼴⼀些。RPC也有⾃⼰的优点，传输协议更⾼效，安全更可控，特别在⼀个公司内部，如果有统⼀个 的开发规范和统⼀的服务框架时，他的开发效率优势更明显些。就看各⾃的技术积累实际条件，⾃⼰的选择了。
⽽异步消息的⽅式在分布式系统中有特别⼴泛的应⽤，他既能减低调⽤服务之间的耦合，⼜能成为调⽤之间的缓冲，确保消息积压不会冲垮被调⽤⽅，同时能保证调⽤⽅的服务体验，继续⼲⾃⼰该⼲的活，不⾄于被后台性能拖慢。不过需要付出的代价是⼀致性的减弱，需要接受数据最终⼀致性；还有就是后台服务⼀般要 实现幂等性，因为消息发送出于性能的考虑⼀般会有重复（保证消息的被收到且仅收到⼀次对性能是很⼤的考验）；最后就是必须引⼊⼀个独⽴的broker，如果公司内部没有技术积累，对broker分布式管理也是⼀个很⼤的挑战。
3、如此多的服务，如何实现？

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。