Seeing that the concept of "microservice architecture" is so popular recently, as a motivated programmer, Cheng Xiaopang couldn't help but want to learn. And the architect Lao Wang (not the next door Lao Wang) has just been doing microservice research and implementation of the company's basic services recently, and has deeply studied this.
So Cheng Xiaopang immediately ran over to ask Lao Wang for advice: "Brother Wang, I see that the microservice architecture is so popular, and I want to learn it too. Can you tell me what a microservice architecture is?"
Lao Wang smiled and said, "To know what microservice architecture is, you must first know what system architecture design is."
Cheng Xiaopang's ideal is to become an architect. He has accumulated a lot of knowledge, so he is very familiar with the concept of "system architecture design", so he immediately gave the answer [1] :
The system architecture design describes how to divide the application system into different parts according to various factors such as business, technology, organization, flexibility, scalability, and maintainability, and make these parts between each other. A way of dividing and cooperating with each other to provide users with a certain value.
Lao Wang nodded with satisfaction and continued to ask: "Look at the recent research and implementation of microservices, do you know why I am doing this?"
"Because the current three-tier architecture has many drawbacks, it does not meet the needs of business development."
"Yes, I think you are very familiar with the current structure of the company. Let's talk about the current three-tier structure in detail."
So Cheng Xiaopang took a piece of A4 paper, and explained to Lao Wang his understanding of the three-layer structure with pictures and texts:
The three-tier architecture means that in the process of business and technology development, the parts with different responsibilities in the system are defined at different levels, and the functions responsible for each layer are more specific. The three-tier architecture usually includes the presentation layer, the business logic layer and the data access layer. The layers are connected and cooperated with each other to form a whole, and the interior of the layer can be replaced with other parts that can work, but the impact on the whole Not much.
Taking a web application as an example, in the early days, all presentation logic, business logic and data access logic were put together, which is a one-tier architecture.
Later, with the development of high-level languages such as java and .NET, more and more convenient data access mechanisms were provided, such as JDBC of java and ADO.NET of .NET. At this time, the data access part is separated, forming a two-tier architecture.
Later, with the continuous development of concepts such as object-oriented design and enterprise architecture patterns, presentation logic and business logic were also separated, forming the current three-tier architecture.
The specific content of the three-tier architecture is as follows:
- Presentation layer: The part that users see, hear, type in, or interact with when using the application.
- Business logic layer: The part that performs logical calculation or business processing according to the information input by the user.
- Data Access Layer: Focuses on the part that effectively manipulates raw data, such as storing data to storage media (such as databases, file systems) and reading data from storage media.
Lao Wang was very satisfied with this explanation and made further additions: "You see that although the program is now divided into three layers, it is only logically layered, not physical. In terms of code, after compiling, packaging and deploying, all the code ends up running in the same process. And this is the so-called monolithic architecture.”
Cheng Xiaopang scratched his head: "So that's what the single-block architecture means~~"
"Well. Based on your actual work experience, you can summarize the advantages and disadvantages of the single-block architecture."
Cheng Xiaopang, who is usually diligent in summarizing, quickly listed the advantages and disadvantages of the monolithic architecture:
advantage:
- Easy to develop: The development method is simple, IDE support is good, and it is convenient to run and debug.
- Ease of testing: All functions run in a process, and once the process is started, system testing is possible.
- Easy to deploy: Just publish a packaged package to the server.
- Easy to scale horizontally: You only need to create a server node, configure the runtime environment, and then publish the software package to the new server node to run the program (of course, you need to adopt a distribution strategy to ensure that requests can be effectively distributed to new nodes).
shortcoming:
- High maintenance cost: When the functions of the application become more and more and the team becomes larger and larger, the communication cost and management cost increase significantly. When a bug occurs, there are more and more combinations of possible causes, which increases the cost of analysis, location, and repair; and in the absence of a deep understanding of global functions, it is easy to introduce new bugs when fixing bugs.
- Long Continuous Delivery Cycles: Build and deployment times increase as features are added, and any minor modification triggers the deployment pipeline.
- Long training cycle for new recruits: New recruits take longer and longer to understand the background, be familiar with the business and configure the environment.
- High cost of technology selection: A single-block architecture tends to use a unified technology platform or solution to solve all problems. If you want to introduce new technologies or frameworks in the future, the cost and risk are high.
- 可扩展性差： 随着功能的增加，垂直扩展的成本将会越来越大；而对于水平扩展而言，因为所有代码都运行在同一个进程，没办法做到针对应用程序的部分功能做独立的扩展。
老王拍了拍成小胖的肩膀，眼睛眯成了一条缝：“小伙子总结的很不错！既然你已经对目前的单块架构的优缺点有了很好的理解，那现在咱们就可以开始来学习微服务架构了。”
老王先从网上搜索“微服务架构”关键字，出来这么一段话：
微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务于服务间采用轻量级的通信机制互相沟通（通常是基于 HTTP 的 RESTful API）。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建。
成小胖看完了这段话，说：“看着有点晕，云里雾里的感觉……”
老王嘿嘿一笑：“莫慌，现在就给你详细讲讲微服务架构的特性。”
1. 单一职责
微服务架构中的每个服务，都是具有业务逻辑的，符合高内聚、低耦合原则以及单一职责原则的单元，不同的服务通过“管道”的方式灵活组合，从而构建出庞大的系统。
2. 轻量级通信
服务之间通过轻量级的通信机制实现互通互联，而所谓的轻量级，通常指语言无关、平台无关的交互方式。
对于轻量级通信的格式而言，我们熟悉的 XML 和 JSON，它们是语言无关、平台无关的；对于通信的协议而言，通常基于 HTTP，能让服务间的通信变得标准化、无状态化。目前大家熟悉的 REST（Representational State Transfer）是实现服务间互相协作的轻量级通信机制之一。使用轻量级通信机制，可以让团队选择更适合的语言、工具或者平台来开发服务本身。
3. 独立性
每个服务在应用交付过程中，独立地开发、测试和部署。
在单块架构中所有功能都在同一个代码库，功能的开发不具有独立性；当不同小组完成多个功能后，需要经过集成和回归测试，测试过程也不具有独立性；当测试完成后，应用被构建成一个包，如果某个功能存在 bug，将导致整个部署失败或者回滚。
在微服务架构中，每个服务都是独立的业务单元，与其他服务高度解耦，只需要改变当前服务本身，就可以完成独立的开发、测试和部署。
4. 进程隔离
单块架构中，整个系统运行在同一个进程中，当应用进行部署时，必须停掉当前正在运行的应用，部署完成后再重启进程，无法做到独立部署。
有时候我们会将重复的代码抽取出来封装成组件，在单块架构中，组件通常的形态叫做共享库（如 jar 包或者 DLL），但是当程序运行时，所有组件最终也会被加载到同一进程中运行。
在微服务架构中，应用程序由多个服务组成，每个服务都是高度自治的独立业务实体，可以运行在独立的进程中，不同的服务能非常容易地部署到不同的主机上。
理论上所有服务可以部署在同一个服务器节点，但是并不推荐这么做，因为微服务架构的主旨就是高度自治和高度隔离。
“王哥你真厉害，您这么一说我的思维清晰了很多！”成小胖激动的几乎要叫起来。
“我之前了解过 SOA，好像跟微服务架构的思想很像啊，您能帮我区分一下吗？”成小胖追问到。
老王嘿嘿一笑，拿起成小胖手上的A4纸，翻到另外一面画了个表格：
| SOA实现 | 微服务架构实现 |
| 企业级，自顶向下开展实施 | 团队级，自底向上开展实施 |
| 服务由多个子系统组成，粒度大 | 一个系统被拆分成多个服务，粒度细 |
| 企业服务总线，集中式的服务架构 | 无集中式总线，松散的服务架构 |
| 集成方式复杂（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】图片源及内容主要参考《微服务架构与实践》。
看到最近“微服务架构”这个概念这么火，作为一个积极上进的程序猿，成小胖忍不住想要学习学习。而架构师老王（不是隔壁老王）最近刚好在做公司基础服务的微服务化研究和落地，对此深有研究。
于是成小胖马上屁颠屁颠的跑过去向老王请教：“王哥，我看微服务架构这么火，我也想学，您给我讲讲啥是微服务架构呗？”
老王笑了笑说：“要想知道什么是微服务架构，你得先知道什么系统架构设计。”
成小胖的理想是成为一名架构师，平时积累了不少知识，因此对“系统架构设计”这个概念还是很熟悉的，因此他马上就给出了答案【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）是实现服务间互相协作的轻量级通信机制之一。使用轻量级通信机制，可以让团队选择更适合的语言、工具或者平台来开发服务本身。
3. 独立性
每个服务在应用交付过程中，独立地开发、测试和部署。
在单块架构中所有功能都在同一个代码库，功能的开发不具有独立性；当不同小组完成多个功能后，需要经过集成和回归测试，测试过程也不具有独立性；当测试完成后，应用被构建成一个包，如果某个功能存在 bug，将导致整个部署失败或者回滚。
在微服务架构中，每个服务都是独立的业务单元，与其他服务高度解耦，只需要改变当前服务本身，就可以完成独立的开发、测试和部署。
4. 进程隔离
单块架构中，整个系统运行在同一个进程中，当应用进行部署时，必须停掉当前正在运行的应用，部署完成后再重启进程，无法做到独立部署。
有时候我们会将重复的代码抽取出来封装成组件，在单块架构中，组件通常的形态叫做共享库（如 jar 包或者 DLL），但是当程序运行时，所有组件最终也会被加载到同一进程中运行。
在微服务架构中，应用程序由多个服务组成，每个服务都是高度自治的独立业务实体，可以运行在独立的进程中，不同的服务能非常容易地部署到不同的主机上。
理论上所有服务可以部署在同一个服务器节点，但是并不推荐这么做，因为微服务架构的主旨就是高度自治和高度隔离。
“王哥你真厉害，您这么一说我的思维清晰了很多！”成小胖激动的几乎要叫起来。
“我之前了解过 SOA，好像跟微服务架构的思想很像啊，您能帮我区分一下吗？”成小胖追问到。
老王嘿嘿一笑，拿起成小胖手上的A4纸，翻到另外一面画了个表格：
| SOA实现 | 微服务架构实现 |
| 企业级，自顶向下开展实施 | 团队级，自底向上开展实施 |
| 服务由多个子系统组成，粒度大 | 一个系统被拆分成多个服务，粒度细 |
| 企业服务总线，集中式的服务架构 | 无集中式总线，松散的服务架构 |
| 集成方式复杂（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】图片源及内容主要参考《微服务架构与实践》。