1. 你了解微服务吗？SOA和微服务有何差异？
微服务架构被认为是目前最适合开发高可扩展性应用的架构风格，微服务架构致力于解决大型、复杂的应用的各种问题。它是一种基于服务的架构，这些服务可独立部署，作为基础的组件。微服务架构在整个开发、测试等开发周期中提供了更好的控制，但它在服务分类方面有一些限制。微服务架构还使用了服务间的通信协议（REST、JSON等）。
SOA架构可以由多种定义方式，这是因为SOA架构风格一直在不断地发展演进。它为企业级软件的复杂组合带来了秩序——通过把它们表示为服务的集合。SOA还使用了服务通信协议，SOA可以被认为是微服务的超集。
SOA架构依赖于共享数据模型。此模型在大量数据结构和模型和分层之间有复杂的关系。SOA的分层组织结构有利于服务协调和消息通信功能。
SOA是基于共享数据模型的，因此，可以预估它在服务和其它系统组件之间存在数据紧耦合的现象。这使得它难以做改变。一些附带的重测是必要的，以确保改变不影响现有的任何服务。
微服务架构存在上下文边界的概念，这使得它在单个服务和数据之间存在关联。
SOA架构的多层模型以中央的消息通信中间件层为主要特征。而对于微服务架构，在组成应用的各种服务之上就存在一个非协调的API层。
通过一个中央集线控制器，SOA维护了服务执行的顺序。而微服务使用了服务间的通信协议来维护服务执行的顺序。
SOA架构致力于解决在复杂的企业系统中的异构应用，促成跨应用和功能的共享服务。而微服务架构是面向基于Web的、更小的、不太复杂的应用程序的最佳架构方式，这些应用程序不需要明确的服务协调。2. 到底在什么样的情况才适合使用微服务架构？
如果遇到了以下的情况，应该采用微服务架构：
1）系统越来越庞大，新功能开发或修改功能变得越来越耗时
2）系统的复杂度极高，模块间紧耦合严重，整体扩展性差
3）系统性能不高，通过扩展也难以提升性能
4）系统的可维护性越来越差3. 服务与服务之间的事务怎么做?接口的调用权限如何控制,粒度在方法级别的？
我通常是这么解决的。在基础服务的上层封装面向事务处理的服务（这里我称为A服务），A服务依赖于下层的多个基础服务，一个A服务就是一个完整的事务处理过程，它内部是调用下层的多个服务共同完成功能的。如果A服务执行失败，则做相应的回退等处理；如果A服务执行成功，那么继续。
微服务架构的服务之间的调用，可以通过REST接口，还可以用RPC、消息通信等方式。以REST接口为例，服务间通过内网或专线方式进行调用，以保证速度。对外则使用API网关来做访问控制。4. 为什么有人说“玩不起”？较比普通架构需要多做那些工作？
微服务架构要设计好并不容易。我的建议是根据具体的需求具体分析，通用的原则也不少。
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
难以对比 SOA 和微服务的原因在于，它们的定义留有很大的解释空间。如果您仅拥有这两个概念的表面知识，可能会觉得它们很相似。一些关键方面（比如组件化、解耦和标准化通信协议）描述了最近几十年的大部分软件举措，所以我们需要进行更深入地分析。
考虑以下简单定义：
微服务架构是一种构造应用程序的替代性方法。应用程序被分解为更小、完全独立的组件，这使得它们拥有更高的敏捷性、可伸缩性和可用性。
SOA将应用程序的功能公开为更容易访问的服务接口，使得在下一代应用程序中使用它们的数据和逻辑变得更容易。
如下图演示了这些定义。SOA 似乎拥有 企业范围，应用程序在该范围内彼此通信。SOA 通过应用程序之间的标准化接口来公开服务。微服务架构似乎拥有 应用程序范围，仅关注一个应用程序内的结构和组件。
架构设计---soa与msa的概念
1. 前言随着现在互联网行业的发展，越来越多的框架、中间件、容器等开源技术不断地涌现，更好地来服务于业务，实现业务并解决问题。然而面对众多的技术选择，我们要如何甄别出适合自己团队业务的技术呢？对于人来...
微服务与SOA架构
【编者的话】本文是Mark Richards写的微服务与面向服务架构完整报告。
基于服务架构的世界
微服务和SOA都被认为是基于服务的架构，这意味着这两种架构模式都非常强调将“服务”作为其架构中的...
微服务架构（MSA）
什么是微服务架构从业界的讨论来看，微服务本身并没有一个严格的定义。不过，ThoughtWorks的首席科学家（Martin Flowler）的描述更加通俗易懂：
微服务架构是一种架构模式，它提倡将...
简述 Microservices（微服务）
自 2014 年始，Microservices（微服务）一词越来越火爆，不谈 Microservices 彷佛就 out 了。那么什么是 Microservices？Microservices 架构与...
一、MSA 简介
1.1、MSA 是什么
微服务架构 MSA 是 Microservice Architect 的简称，它是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之...
WHAT - 什么是微服务
微服务简介
这次参加JavaOne2015最大的困难就是听Microservice相关的session，无论内容多么水，只要题目带microservice，必定...
Atitit 微服务之道 attilax著
1. 什么是微服务架构？ 1
1.1. 、微服务与SOA的关系 :微服务架架构师面向服务架构（SOA）的一种特定实现
1.2. 微服务与康威定...
软件工程发展软件工程发展大师级人物Martin Fowler在他谈论微服务的个人主页上提到，微服务并没有一个非常明确的定义。事实上有很多种分布式系统的实现都可以被看成（或者说勉强看成）是面向微服务架构...
转载自：https://blog.maxleap.cn/archives/195
引言：“微服务”是当前软件架构领域非常热门的词汇，能找到很多关于微服务的定义、准则，以及如何从微服务中获益的...
没有更多推荐了，微服务架构
- Go语言中文网 - Golang中文社区
<meta name="author" content="polaris ">
微服务架构
· 2067 次点击 ·
开始浏览 & &
看到最近“微服务架构”这个概念这么火，作为一个积极上进的程序猿，成小胖忍不住想要学习学习。而架构师老王（不是隔壁老王）最近刚好在做公司基础服务的微服务化研究和落地，对此深有研究。
于是成小胖马上屁颠屁颠的跑过去向老王请教：“王哥，我看微服务架构这么火，我也想学，您给我讲讲啥是微服务架构呗？”
老王笑了笑说：“要想知道什么是微服务架构，你得先知道什么系统架构设计。”
成小胖的理想是成为一名架构师，平时积累了不少知识，因此对“系统架构设计”这个概念还是很熟悉的，因此他马上就给出了答案【1】：
系统架构设计描述了在应用系统的内部，如何根据业务、技术、组织、灵活性、可扩展性以及可维护性等多种因素，将应用系统划分成不同的部分，并使这些部分彼此之间相互分工、相互协作，从而为用户提供某种特定的价值的方式。
老王满意的点点头，继续问：“你看最近我在做微服务的研究和落地，你知道为什么要做这个事情吗？”
“因为目前的三层架构存在很多弊端，不满足业务发展的需求了呗。”
“对的，我看你对公司目前的架构也非常熟悉了，你来仔细说说现在的三层架构吧。”
于是成小胖拿了一张A4纸，图文并茂地给老王讲了他对三层架构的理解：
三层架构是指在业务和技术的发展过程中，系统中不同职责的部分被定义在不同的层次，每一层负责的功能更加具体化。三层架构通常包括表示层、业务逻辑层和数据访问层，层与层之间互相连接、互相协作，构成一个整体，并且层的内部可以被替换成其他可以工作的部分，但对整体的影响不大。
以 Web 应用程序为例，早期是将所有的表示逻辑、业务逻辑和数据访问逻辑放在一起，这就是一层架构。
后来随着 java、.NET 等高级语言的发展，提供了越来越方便的数据访问机制，如 java 的 JDBC 和 .NET 的 ADO.NET。这时数据访问部分被分离开来，形成了二层架构。
再后来，随着面向对象设计、企业架构模式等理念的不断发展，表示逻辑和业务逻辑也被分离开来，形成了现在的三层架构。
三层架构的具体内容如下：
表示层： 用户使用应用程序时，看到的、听见的、输入的或者交互的部分。
业务逻辑层： 根据用户输入的信息，进行逻辑计算或者业务处理的部分。
数据访问层： 关注有效地操作原始数据的部分，如将数据存储到存储介质（如数据库、文件系统）及从存储介质中读取数据等。
老王对这个解释非常满意，作了进一步的补充：“你看虽然现在程序被分成了三层，但只是逻辑上的分层，并不是物理上的分层。也就是说，对不同层的代码而言，经过编译、打包和部署后，所有的代码最终还是运行在同一个进程中。而这，就是所谓的单块架构。”
成小胖挠了挠头：“原来单块架构是这个意思啊~~”
“嗯。根据你的实际工作经验，你再总结下单块架构的优缺点吧。”
平时勤于总结的成小胖很快便列出了单块架构的优缺点：
易于开发： 开发方式简单，IDE 支持好，方便运行和调试。
易于测试： 所有功能运行在一个进程中，一旦进程启动，便可以进行系统测试。
易于部署： 只需要将打好的一个软件包发布到服务器即可。
易于水平伸缩： 只需要创建一个服务器节点，配置好运行时环境，再将软件包发布到新服务器节点即可运行程序（当然也需要采取分发策略保证请求能有效地分发到新节点）。
维护成本大： 当应用程序的功能越来越多、团队越来越大时，沟通成本、管理成本显著增加。当出现 bug 时，可能引起 bug 的原因组合越来越多，导致分析、定位和修复的成本增加；并且在对全局功能缺乏深度理解的情况下，容易在修复 bug 时引入新的 bug。
持续交付周期长： 构建和部署时间会随着功能的增多而增加，任何细微的修改都会触发部署流水线。
新人培养周期长： 新成员了解背景、熟悉业务和配置环境的时间越来越长。
技术选型成本高： 单块架构倾向于采用统一的技术平台或方案来解决所有问题，如果后续想引入新的技术或框架，成本和风险都很大。
可扩展性差： 随着功能的增加，垂直扩展的成本将会越来越大；而对于水平扩展而言，因为所有代码都运行在同一个进程，没办法做到针对应用程序的部分功能做独立的扩展。
老王拍了拍成小胖的肩膀，眼睛眯成了一条缝：“小伙子总结的很不错！既然你已经对目前的单块架构的优缺点有了很好的理解，那现在咱们就可以开始来学习微服务架构了。”
老王先从网上搜索“微服务架构”关键字，出来这么一段话：
微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务于服务间采用轻量级的通信机制互相沟通（通常是基于 HTTP 的 RESTful API）。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建。
成小胖看完了这段话，说：“看着有点晕，云里雾里的感觉……”
老王嘿嘿一笑：“莫慌，现在就给你详细讲讲微服务架构的特性。”
1. 单一职责
微服务架构中的每个服务，都是具有业务逻辑的，符合高内聚、低耦合原则以及单一职责原则的单元，不同的服务通过“管道”的方式灵活组合，从而构建出庞大的系统。
2. 轻量级通信
服务之间通过轻量级的通信机制实现互通互联，而所谓的轻量级，通常指语言无关、平台无关的交互方式。
对于轻量级通信的格式而言，我们熟悉的 XML 和 JSON，它们是语言无关、平台无关的；对于通信的协议而言，通常基于 HTTP，能让服务间的通信变得标准化、无状态化。目前大家熟悉的 REST（Representational State Transfer）是实现服务间互相协作的轻量级通信机制之一。使用轻量级通信机制，可以让团队选择更适合的语言、工具或者平台来开发服务本身。
每个服务在应用交付过程中，独立地开发、测试和部署。
在单块架构中所有功能都在同一个代码库，功能的开发不具有独立性；当不同小组完成多个功能后，需要经过集成和回归测试，测试过程也不具有独立性；当测试完成后，应用被构建成一个包，如果某个功能存在 bug，将导致整个部署失败或者回滚。
在微服务架构中，每个服务都是独立的业务单元，与其他服务高度解耦，只需要改变当前服务本身，就可以完成独立的开发、测试和部署。
4. 进程隔离
单块架构中，整个系统运行在同一个进程中，当应用进行部署时，必须停掉当前正在运行的应用，部署完成后再重启进程，无法做到独立部署。
有时候我们会将重复的代码抽取出来封装成组件，在单块架构中，组件通常的形态叫做共享库（如 jar 包或者 DLL），但是当程序运行时，所有组件最终也会被加载到同一进程中运行。
在微服务架构中，应用程序由多个服务组成，每个服务都是高度自治的独立业务实体，可以运行在独立的进程中，不同的服务能非常容易地部署到不同的主机上。
理论上所有服务可以部署在同一个服务器节点，但是并不推荐这么做，因为微服务架构的主旨就是高度自治和高度隔离。
“王哥你真厉害，您这么一说我的思维清晰了很多！”成小胖激动的几乎要叫起来。
“我之前了解过 SOA，好像跟微服务架构的思想很像啊，您能帮我区分一下吗？”成小胖追问到。
老王嘿嘿一笑，拿起成小胖手上的A4纸，翻到另外一面画了个表格：
微服务架构实现
企业级，自顶向下开展实施
团队级，自底向上开展实施
服务由多个子系统组成，粒度大
一个系统被拆分成多个服务，粒度细
企业服务总线，集中式的服务架构
无集中式总线，松散的服务架构
集成方式复杂（ESB/WS/SOAP）
集成方式简单（HTTP/REST/JSON）
单块架构系统，相互依赖，部署复杂
服务能独立部署
接着老王又画了一张图：
成小胖看了之后说：“您这么一画我倒是大概明白了，但是图里面的 DevOps 这个概念我不懂诶……”
“这个 DevOps 就说来话长了，有时间你自己先去查查资料了解下吧。”
“好的。现在我对微服务架构的概念有了了解，您能再深入剖析下它的本质吗？”
“好，你可仔细听好了哈！”
1. 服务作为组件
微服务也可以被认为是一种组件，但是跟传统组件的区别在于它可以独立部署，因此它的一个显著的优势。另外一个优点是，它在组件与组件之间定义了清晰的、语言无关、平台无关的规范接口，耦合度低，灵活性非常高。但它的不足之处是，分布式调用严重依赖于网络的可靠性和稳定性。
2. 围绕业务组织团队
在单块架构中，企业一般会根据技能划分团队，在这种组织架构下，即便是简单的需求变更都有可能需要跨团队协作，沟通成本很高。而在微服务架构中，它提倡以业务为核心，按照业务能力来组织团队，团队中的成员具有多样性的技能。
3. 关注产品而非项目
在单块架构中，应用基本上是基于“项目模式”构建的，即项目启动时从不同技能资源池中抽取相关资源组成团队，项目结束后释放所有资源。这种情况下团队成员缺乏主人翁意识和产品成就感。
在微服务架构中，提倡采用“产品模式”构建，即更倾向于让团队负责整个服务的生命周期，以便提供更优质的服务。
4. 技术多样性
微服务架构中，提倡针对不同的业务特征选择合适的技术方案，有针对性的解决具体业务问题，而不是像单块架构中采用统一的平台或技术来解决所有问题。
5. 业务数据独立
微服务架构提供自主管理其相关的业务数据，这样可以随着业务的发展提供数据接口集成，而不是以数据库的方式同其他服务集成。另外，随着业务的发展，可以方便地选择更合的工具管理或者迁移业务数据。
6. 基础设施自动化
在微服务架构的实践过程中，对持续交付和部署流水线的要求很高，将促进企业不断寻找更高效的方式完成基础设施的自动化及 DevOps 运维能力的提升。
听完成小胖忍不住表达了敬佩之意：“老司机就是老司机，噢说错了……架构师就是架构师，总结得这么简洁又深刻！”
“咳咳，低调低调……”
“听您讲解了这么多，我觉得微服务架构解决了很多当前三层架构的痛点。不过我觉得没有任何一项技术或架构是完美的。”
“非常正确。进行微服务架构的落地是存在很多挑战的。”
1. 分布式系统的复杂性
微服务架构是基于分布式的系统，而构建分布式系统必然会带来额外的开销。
性能： 分布式系统是跨进程、跨网络的调用，受网络延迟和带宽的影响。
可靠性： 由于高度依赖于网络状况，任何一次的远程调用都有可能失败，随着服务的增多还会出现更多的潜在故障点。因此，如何提高系统的可靠性、降低因网络引起的故障率，是系统构建的一大挑战。
异步： 异步通信大大增加了功能实现的复杂度，并且伴随着定位难、调试难等问题。
数据一致性： 要保证分布式系统的数据强一致性，成本是非常高的，需要在 C（一致性）A（可用性）P（分区容错性） 三者之间做出权衡。
2. 运维成本
运维主要包括配置、部署、监控与告警和日志收集四大方面。微服务架构中，每个服务都需要独立地配置、部署、监控和收集日志，成本呈指数级增长。
3. 自动化部署
在微服务架构中，每个服务都独立部署，交付周期短且频率高，人工部署已经无法适应业务的快速变化。因此如何有效地构建自动化部署体系，是微服务面临的另一个挑战。
4. DevOps 与组织架构
在微服务架构的实施过程中，开发人员和运维人员的角色发生了变化，开发者将承担起整个服务的生命周期的责任，包括部署和监控；而运维则更倾向于顾问式的角色，尽早考虑服务如何部署。因此，按需调整组织架构、构建全功能的团队，也是一个不小的挑战。
5. 服务间的依赖测试
单块架构中，通常使用集成测试来验证依赖是否正常。而在微服务架构中，服务数量众多，每个服务都是独立的业务单元，服务主要通过接口进行交互，如何保证依赖的正常，是测试面临的主要挑战。
6. 服务间的依赖管理
微服务架构中，服务数量众多，如何清晰有效地展示服务间的依赖关系也是个不小的挑战。
“微服务的落地需要经过全面的考察和完善的试验，并不是每个场景都适合使用微服务架构，也不是每个企业都有能力或者精力去面对这些挑战。”老王最后语重心长的说。
“嗯嗯，每件事都有两面性，最合适的才是最好的！对了王哥，您已经给我上完理论课了，啥时候带我实践下呗？”
“你先好好消化完今天讲的这些，下次再说吧……”
“好吧，很期待我们的下一次交流……”
【1】图片源及内容主要参考《微服务架构与实践》。
2067 次点击 &
被以下专栏收入，发现更多相似内容
4 回复 &| &直到
请尽量让自己的回复能够对别人有帮助
支持 Markdown 格式, **粗体**、~~删除线~~、`单行代码`
支持 @ 本站用户；支持表情（输入 : 提示），见
图片支持拖拽、截图粘贴等方式上传
记住登录状态
看到最近“微服务架构”这个概念这么火，作为一个积极上进的程序猿，成小胖忍不住想要学习学习。而架构师老王（不是隔壁老王）最近刚好在做公司基础服务的微服务化研究和落地，对此深有研究。
于是成小胖马上屁颠屁颠的跑过去向老王请教：“王哥，我看微服务架构这么火，我也想学，您给我讲讲啥是微服务架构呗？”
老王笑了笑说：“要想知道什么是微服务架构，你得先知道什么系统架构设计。”
成小胖的理想是成为一名架构师，平时积累了不少知识，因此对“系统架构设计”这个概念还是很熟悉的，因此他马上就给出了答案【1】：
系统架构设计描述了在应用系统的内部，如何根据业务、技术、组织、灵活性、可扩展性以及可维护性等多种因素，将应用系统划分成不同的部分，并使这些部分彼此之间相互分工、相互协作，从而为用户提供某种特定的价值的方式。
老王满意的点点头，继续问：“你看最近我在做微服务的研究和落地，你知道为什么要做这个事情吗？”
“因为目前的三层架构存在很多弊端，不满足业务发展的需求了呗。”
“对的，我看你对公司目前的架构也非常熟悉了，你来仔细说说现在的三层架构吧。”
于是成小胖拿了一张A4纸，图文并茂地给老王讲了他对三层架构的理解：
三层架构是指在业务和技术的发展过程中，系统中不同职责的部分被定义在不同的层次，每一层负责的功能更加具体化。三层架构通常包括表示层、业务逻辑层和数据访问层，层与层之间互相连接、互相协作，构成一个整体，并且层的内部可以被替换成其他可以工作的部分，但对整体的影响不大。
以 Web 应用程序为例，早期是将所有的表示逻辑、业务逻辑和数据访问逻辑放在一起，这就是一层架构。
后来随着 java、.NET 等高级语言的发展，提供了越来越方便的数据访问机制，如 java 的 JDBC 和 .NET 的 ADO.NET。这时数据访问部分被分离开来，形成了二层架构。
再后来，随着面向对象设计、企业架构模式等理念的不断发展，表示逻辑和业务逻辑也被分离开来，形成了现在的三层架构。
三层架构的具体内容如下：
表示层： 用户使用应用程序时，看到的、听见的、输入的或者交互的部分。
业务逻辑层： 根据用户输入的信息，进行逻辑计算或者业务处理的部分。
数据访问层： 关注有效地操作原始数据的部分，如将数据存储到存储介质（如数据库、文件系统）及从存储介质中读取数据等。
老王对这个解释非常满意，作了进一步的补充：“你看虽然现在程序被分成了三层，但只是逻辑上的分层，并不是物理上的分层。也就是说，对不同层的代码而言，经过编译、打包和部署后，所有的代码最终还是运行在同一个进程中。而这，就是所谓的单块架构。”
成小胖挠了挠头：“原来单块架构是这个意思啊~~”
“嗯。根据你的实际工作经验，你再总结下单块架构的优缺点吧。”
平时勤于总结的成小胖很快便列出了单块架构的优缺点：
易于开发： 开发方式简单，IDE 支持好，方便运行和调试。
易于测试： 所有功能运行在一个进程中，一旦进程启动，便可以进行系统测试。
易于部署： 只需要将打好的一个软件包发布到服务器即可。
易于水平伸缩： 只需要创建一个服务器节点，配置好运行时环境，再将软件包发布到新服务器节点即可运行程序（当然也需要采取分发策略保证请求能有效地分发到新节点）。
维护成本大： 当应用程序的功能越来越多、团队越来越大时，沟通成本、管理成本显著增加。当出现 bug 时，可能引起 bug 的原因组合越来越多，导致分析、定位和修复的成本增加；并且在对全局功能缺乏深度理解的情况下，容易在修复 bug 时引入新的 bug。
持续交付周期长： 构建和部署时间会随着功能的增多而增加，任何细微的修改都会触发部署流水线。
新人培养周期长： 新成员了解背景、熟悉业务和配置环境的时间越来越长。
技术选型成本高： 单块架构倾向于采用统一的技术平台或方案来解决所有问题，如果后续想引入新的技术或框架，成本和风险都很大。
可扩展性差： 随着功能的增加，垂直扩展的成本将会越来越大；而对于水平扩展而言，因为所有代码都运行在同一个进程，没办法做到针对应用程序的部分功能做独立的扩展。
老王拍了拍成小胖的肩膀，眼睛眯成了一条缝：“小伙子总结的很不错！既然你已经对目前的单块架构的优缺点有了很好的理解，那现在咱们就可以开始来学习微服务架构了。”
老王先从网上搜索“微服务架构”关键字，出来这么一段话：
微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务于服务间采用轻量级的通信机制互相沟通（通常是基于 HTTP 的 RESTful API）。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建。
成小胖看完了这段话，说：“看着有点晕，云里雾里的感觉……”
老王嘿嘿一笑：“莫慌，现在就给你详细讲讲微服务架构的特性。”
1. 单一职责
微服务架构中的每个服务，都是具有业务逻辑的，符合高内聚、低耦合原则以及单一职责原则的单元，不同的服务通过“管道”的方式灵活组合，从而构建出庞大的系统。
2. 轻量级通信
服务之间通过轻量级的通信机制实现互通互联，而所谓的轻量级，通常指语言无关、平台无关的交互方式。
对于轻量级通信的格式而言，我们熟悉的 XML 和 JSON，它们是语言无关、平台无关的；对于通信的协议而言，通常基于 HTTP，能让服务间的通信变得标准化、无状态化。目前大家熟悉的 REST（Representational State Transfer）是实现服务间互相协作的轻量级通信机制之一。使用轻量级通信机制，可以让团队选择更适合的语言、工具或者平台来开发服务本身。
每个服务在应用交付过程中，独立地开发、测试和部署。
在单块架构中所有功能都在同一个代码库，功能的开发不具有独立性；当不同小组完成多个功能后，需要经过集成和回归测试，测试过程也不具有独立性；当测试完成后，应用被构建成一个包，如果某个功能存在 bug，将导致整个部署失败或者回滚。
在微服务架构中，每个服务都是独立的业务单元，与其他服务高度解耦，只需要改变当前服务本身，就可以完成独立的开发、测试和部署。
4. 进程隔离
单块架构中，整个系统运行在同一个进程中，当应用进行部署时，必须停掉当前正在运行的应用，部署完成后再重启进程，无法做到独立部署。
有时候我们会将重复的代码抽取出来封装成组件，在单块架构中，组件通常的形态叫做共享库（如 jar 包或者 DLL），但是当程序运行时，所有组件最终也会被加载到同一进程中运行。
在微服务架构中，应用程序由多个服务组成，每个服务都是高度自治的独立业务实体，可以运行在独立的进程中，不同的服务能非常容易地部署到不同的主机上。
理论上所有服务可以部署在同一个服务器节点，但是并不推荐这么做，因为微服务架构的主旨就是高度自治和高度隔离。
“王哥你真厉害，您这么一说我的思维清晰了很多！”成小胖激动的几乎要叫起来。
“我之前了解过 SOA，好像跟微服务架构的思想很像啊，您能帮我区分一下吗？”成小胖追问到。
老王嘿嘿一笑，拿起成小胖手上的A4纸，翻到另外一面画了个表格：
微服务架构实现
企业级，自顶向下开展实施
团队级，自底向上开展实施
服务由多个子系统组成，粒度大
一个系统被拆分成多个服务，粒度细
企业服务总线，集中式的服务架构
无集中式总线，松散的服务架构
集成方式复杂（ESB/WS/SOAP）
集成方式简单（HTTP/REST/JSON）
单块架构系统，相互依赖，部署复杂
服务能独立部署
接着老王又画了一张图：
成小胖看了之后说：“您这么一画我倒是大概明白了，但是图里面的 DevOps 这个概念我不懂诶……”
“这个 DevOps 就说来话长了，有时间你自己先去查查资料了解下吧。”
“好的。现在我对微服务架构的概念有了了解，您能再深入剖析下它的本质吗？”
“好，你可仔细听好了哈！”
1. 服务作为组件
微服务也可以被认为是一种组件，但是跟传统组件的区别在于它可以独立部署，因此它的一个显著的优势。另外一个优点是，它在组件与组件之间定义了清晰的、语言无关、平台无关的规范接口，耦合度低，灵活性非常高。但它的不足之处是，分布式调用严重依赖于网络的可靠性和稳定性。
2. 围绕业务组织团队
在单块架构中，企业一般会根据技能划分团队，在这种组织架构下，即便是简单的需求变更都有可能需要跨团队协作，沟通成本很高。而在微服务架构中，它提倡以业务为核心，按照业务能力来组织团队，团队中的成员具有多样性的技能。
3. 关注产品而非项目
在单块架构中，应用基本上是基于“项目模式”构建的，即项目启动时从不同技能资源池中抽取相关资源组成团队，项目结束后释放所有资源。这种情况下团队成员缺乏主人翁意识和产品成就感。
在微服务架构中，提倡采用“产品模式”构建，即更倾向于让团队负责整个服务的生命周期，以便提供更优质的服务。
4. 技术多样性
微服务架构中，提倡针对不同的业务特征选择合适的技术方案，有针对性的解决具体业务问题，而不是像单块架构中采用统一的平台或技术来解决所有问题。
5. 业务数据独立
微服务架构提供自主管理其相关的业务数据，这样可以随着业务的发展提供数据接口集成，而不是以数据库的方式同其他服务集成。另外，随着业务的发展，可以方便地选择更合的工具管理或者迁移业务数据。
6. 基础设施自动化
在微服务架构的实践过程中，对持续交付和部署流水线的要求很高，将促进企业不断寻找更高效的方式完成基础设施的自动化及 DevOps 运维能力的提升。
听完成小胖忍不住表达了敬佩之意：“老司机就是老司机，噢说错了……架构师就是架构师，总结得这么简洁又深刻！”
“咳咳，低调低调……”
“听您讲解了这么多，我觉得微服务架构解决了很多当前三层架构的痛点。不过我觉得没有任何一项技术或架构是完美的。”
“非常正确。进行微服务架构的落地是存在很多挑战的。”
1. 分布式系统的复杂性
微服务架构是基于分布式的系统，而构建分布式系统必然会带来额外的开销。
性能： 分布式系统是跨进程、跨网络的调用，受网络延迟和带宽的影响。
可靠性： 由于高度依赖于网络状况，任何一次的远程调用都有可能失败，随着服务的增多还会出现更多的潜在故障点。因此，如何提高系统的可靠性、降低因网络引起的故障率，是系统构建的一大挑战。
异步： 异步通信大大增加了功能实现的复杂度，并且伴随着定位难、调试难等问题。
数据一致性： 要保证分布式系统的数据强一致性，成本是非常高的，需要在 C（一致性）A（可用性）P（分区容错性） 三者之间做出权衡。
2. 运维成本
运维主要包括配置、部署、监控与告警和日志收集四大方面。微服务架构中，每个服务都需要独立地配置、部署、监控和收集日志，成本呈指数级增长。
3. 自动化部署
在微服务架构中，每个服务都独立部署，交付周期短且频率高，人工部署已经无法适应业务的快速变化。因此如何有效地构建自动化部署体系，是微服务面临的另一个挑战。
4. DevOps 与组织架构
在微服务架构的实施过程中，开发人员和运维人员的角色发生了变化，开发者将承担起整个服务的生命周期的责任，包括部署和监控；而运维则更倾向于顾问式的角色，尽早考虑服务如何部署。因此，按需调整组织架构、构建全功能的团队，也是一个不小的挑战。
5. 服务间的依赖测试
单块架构中，通常使用集成测试来验证依赖是否正常。而在微服务架构中，服务数量众多，每个服务都是独立的业务单元，服务主要通过接口进行交互，如何保证依赖的正常，是测试面临的主要挑战。
6. 服务间的依赖管理
微服务架构中，服务数量众多，如何清晰有效地展示服务间的依赖关系也是个不小的挑战。
“微服务的落地需要经过全面的考察和完善的试验，并不是每个场景都适合使用微服务架构，也不是每个企业都有能力或者精力去面对这些挑战。”老王最后语重心长的说。
“嗯嗯，每件事都有两面性，最合适的才是最好的！对了王哥，您已经给我上完理论课了，啥时候带我实践下呗？”
“你先好好消化完今天讲的这些，下次再说吧……”
“好吧，很期待我们的下一次交流……”
【1】图片源及内容主要参考《微服务架构与实践》。
1619 人在线
&最高记录 2928
& studygolang.com Go语言中文网，中国 Golang 社区，致力于构建完善的 Golang 中文社区，Go语言爱好者的学习家园。
Powered by
&o&·&CDN 采用
VERSION: V3.5.0&·&13.876209ms&·&为了更好的体验，本站推荐使用 Chrome 或 Firefox 浏览器
登录和大家一起探讨吧
记住登录状态
还不是会员}