Author: YYGCui
Source: http: //blog.cuicc.com/blog/2015/07/22/microservices/
In the past few years, "micro Services Architecture" as the term sprung up, it describes a specific way software applications designed as a set of services can be deployed independently. While this architectural style is not clearly defined, but there are some common features in the organizational, operational capacity: decentralized control automation deployment, endpoint intelligence, language and data.
"Micro-services" - software architecture crowded on the street there is a new term. While our natural inclination is contemptuous glance at it in passing, but we found that the term describes a software system more attractive style. We have seen, there are many projects using this style in the past few years, and so far the results are pretty good, so that it has become our colleagues use when building enterprise applications default style architecture . Unfortunately, however, is not too much information to summarize what is a micro-service style and how to use this style.
In short, micro-services architecture style [1] is a way to develop a single application for a group of small service approach, each service runs in its own process, the inter-service communication using lightweight communication mechanism (usually HTTP resource API). These services build around business capabilities and can be deployed independently by automatic deployment mechanism. These services are the most common small centralized management services developed in different languages available, using different data storage technologies.
Style compare the monomer helps to explain the micro-service style start: monomer application is constructed as a single unit. Enterprise applications usually consists of three parts: a client-side user interface (by the browser running on the development machine in HTML pages and Javascript composition), database (by the insertion into a number of data tables common relational database management system component ), the server application. Server application processing HTTP requests, performs a logical field, retrieved from the database, update the data, select, to be sent to fill the browser HTTP view. The application server is a single logical executable monomer [2]. Any change in the system will involve a re-build and deploy a new version of the server.
Such monomers to build such a system the server is the most natural way. All logic processing requests are running in a single process, allowing you to use the basic features of the application programming language zoned classification, function, and namespace. You seriously run the test application on the development machine, and use the pipeline to ensure the deployment changes have been properly tested and deployed into the production environment. Horizontal extension of the monomer may be achieved by running multiple instances behind a load balancer.
Monolithic applications can be successful, but there is a growing frustration for them, especially as more applications are deployed in the cloud. Change cycle are bundled together - even if only part of the change of the application, but also need to re-build and deploy entire monomer. Over time, usually it will be difficult to maintain a good modular architecture, which makes it difficult to change only occurs in the module needs to be changed. Program expansion requirements be extended for the entire application rather than the need to extend the application of the additional resources section.
Figure 1: Monomer and microService
These setbacks service-oriented micro-architectural style: build applications for service packs. In addition to the independent service is deployed, expanded outside independently, each service module providing a fixed boundary. Even allows different services in different languages developed by a different team management.
We do not claim that micro-service style is novel, innovative, by its very nature can be traced back at least to the Unix design philosophy. But we do not think enough people to carefully consider the micro-service architecture, and if you use it a lot of software will be better.
Micro-architecture features of the service
We can not give a micro-service architecture style formal definition, but we can try to describe what we see in line with some of the commonalities of the architecture. Outlining any definition of common terms, not all of these are micro-services architecture style in common, but we expect most of the micro-service architecture style exhibits most of the features. Although this writer has been a rather loose active user community, our aim is to try to describe our work and we know some of the team's similar effort saw and heard. In particular, we can not enact comply with the definition.
Through the service component of
As long as we have been engaged in the software industry, a desire that is inserted through the components together to build the system, as in the real world structure the way we see things the same. In the last two decades, we have seen as a platform for most part of the language of the compilation of a large number of public libraries has made great progress.
When it comes to assembly, we encounter difficulties of definition: what components yes. Our definition is: The component is an independent unit replacement and software upgrades independently.
Micro Services Architecture will use the library, but the main way of component-based software is broken down into service. We library is defined as a link to the program and use the memory function call to call the components, and the service is a component outside of a process in which (remote procedure call) via a web service request or rpc communication mechanisms (which are many and object-oriented programs the concept of service objects is different [3].)
A main reason for using the service as an assembly instead of using the library service is available for standalone deployment. If you have an application [4] is composed of multiple libraries in a single process composed of any changes to one component will result in having to redeploy the entire application. But if the application can be decomposed into multiple services, then the change of a single service only need to re-deploy the service can be. Of course, this is not absolute, some changes will change the service interface causes some collaboration, but the purpose of a good micro-service architecture is through cohesion border and on agreement evolved mechanisms to minimize these collaboration.
Another result of using the service as a component of a more explicit component interface. Most languages do not have a good mechanism to define a clear publishing interface. Usually only documents and rules to prevent the client to break the package assembly, which results in too tight coupling between components. Services through a clear mechanism for remote call can easily avoid these.
Like using the service does have some drawbacks, more expensive than long-distance calls within the calling process, so the remote API is designed to coarse-grained, it is often more inconvenient to use. If you need to change the allocation of responsibilities between components when you cross process boundaries, such behavior action more difficult to reach.
Intuitive estimate, we observed that when the process is running one mapping services, but only visual estimate only. Services may be provided by a multi-process composition, these processes are always being developed and deployed together, such as a database application process and are only used this service.
Around the operational capacity of the organization
When the application wants to split into a large member, typically focused on the technical level management, leading to UI team, the server side logic team, the team database division. When the team is divided by lines of these technologies, even simple changes can lead to cross-team's time and budget approval. A smart team will focus on these optimizations, the lesser evil - only the business logic in the application they will enforce access. In other words, the logic everywhere. This rule is Conway [5] In one example functioning.
Any design system (broadly defined) will produce a design organization, his communication structure is the structure of the organization.
-- Melvyn Conway 1967
FIG 2: Conway law at work
Micro-segmentation services using different methods, divided into service around the operational capacity of the organization. These services take the width of the stack of business software implementations, including the user interface, persistent storage, and any external collaboration. Therefore, the team is cross-functional, including the all-round skills development needs: the user experience, database, project management.
Figure 3: Team boundary enhanced service boundary
www.comparethemarket.com is a company organized in this way. Cross-functional team responsible for the creation and operation of the product, the product is divided into a number of individual services that communicate via message bus.
Large monolithic applications can always be around to modular operational capacity, although this is not often the case. Of course, we would urge the creation of a large monolithic applications team will be the team itself split by business line. We see the main problem with this situation is that they tend to be organized around a lot of context. If more than one monomer across module boundaries, individual team members, they are difficult to put into their short-term memory. In addition, we see the modular course requires a lot of rules to enforce. Clearer separation of service components required, making it easier to keep the team clear boundary.
Sidebar: How much micro-services?
Although the "micro-service" has become this architectural style in lieu of that, the name does cause the size of the unfortunate focus on service, and the "micro" what constitutes debated. In dialogue with the micro-service practitioners, we found that there are various sizes of service. Amazon's largest service reports follow two pizza teams (that is, the entire team would eat two pizzas fed) concept, which means that the team does not exceed 12 people. On a smaller size, we see this arrangement, 6-person team will support six service.
This leads to a question, in the range of 1 per individual per serving size of 12 individuals and services, whether there is sufficient play so different that they can not be concentrated in the same micro-label service. Currently, we thought it best to put them together. But with the in-depth exploration of this style, we must be possible to change our views.
Product is not a project
We see most application development projects using a pattern: the goal is to deliver some software to be completed. After the completion of the software is delivered to the maintenance organization, then it build team disbanded.
微服务支持者倾向于避免这种模式，而是认为一个团队应该负责产品的整个生命周期。对此一个共同的启示是亚马逊的理念 “you build, you run it” ，开发团队负责软件的整个产品周期。这使开发者经常接触他们的软件在生产环境如何工作，并增加与他们的用户联系，因为他们必须承担至少部分的支持工作。
产品思想与业务能力紧紧联系在一起。要持续关注软件如何帮助用户提升业务能力，而不是把软件看成是将要完成的一组功能。
没有理由说为什么同样的方法不能用在单体应用程序上，但服务的粒度更小，使得它更容易在服务开发者和用户之间建立个人关系。
智能端点和哑管道
当在不同进程间创建通信结构时，我们已经看到了很多的产品和方法，把显著的智慧强压进通信机制本身。一个很好的例子就是企业服务总线(ESB)，在ESB产品中通常为消息路由、编排(choreography)、转化和应用业务规则引入先进的设施。
微服务社区主张另一种方法：智能端点和哑管道。基于微服务构建的应用程序的目标是尽可能的解耦和尽可能的内聚 - 他们拥有自己的领域逻辑，他们的行为更像经典UNIX理念中的过滤器 - 接收请求，应用适当的逻辑并产生响应。使用简单的REST风格的协议来编排他们，而不是使用像WS-Choreography或者BPEL或者通过中心工具编制(orchestration)等复杂的协议。
最常用的两种协议是使用资源API的HTTP请求-响应和轻量级消息传送[6]。对第一种协议最好的表述是
本身就是web，而不是隐藏在web的后面。
-- Ian Robinson
微服务团队使用的规则和协议，正是构建万维网的规则和协议(在更大程度上，是UNIX的)。从开发者和运营人员的角度讲，通常使用的资源可以很容易的缓存。
第二种常用方法是在轻量级消息总线上传递消息。选择的基础设施是典型的哑的(哑在这里只充当消息路由器) - 像RabbitMQ或ZeroMQ这样简单的实现仅仅提供一个可靠的异步交换结构 - 在服务里，智能仍旧存活于端点中，生产和消费消息。
单体应用中，组件都在同一进程内执行，它们之间通过方法调用或函数调用通信。把单体变成微服务最大的问题在于通信模式的改变。一种幼稚的转换是从内存方法调用转变成RPC，这导致频繁通信且性能不好。相反，你需要用粗粒度通信代替细粒度通信。
去中心化治理
集中治理的一个后果是单一技术平台的标准化发展趋势。经验表明，这种方法正在收缩 - 不是每个问题都是钉子，不是每个问题都是锤子。我们更喜欢使用正确的工具来完成工作，而单体应用程序在一定程度上可以利用语言的优势，这是不常见的。
把单体的组件分裂成服务，在构建这些服务时可以有自己的选择。你想使用Node.js开发一个简单的报告页面？去吧。用C++实现一个特别粗糙的近乎实时的组件？好极了。你想换用一个更适合组件读操作数据的不同风格的数据库？我们有技术来重建它。
当然，仅仅因为你可以做些什么，而不意味着你应该这样做 - 但用这种方式划分系统意味着你可以选择。
团队在构建微服务时也更喜欢用不同的方法来达标。他们更喜欢生产有用的工具这种想法，而不是写在纸上的标准，这样其他开发者可以用这些工具解决他们所面临的相似的问题。有时，这些工具通常在实施中收获并与更广泛的群体共享，但不完全使用一个内部开源模型。现在git和github已经成为事实上的版本控制系统的选择，在内部开放源代码的实践也正变得越来越常见。
侧边栏：微服务和SOA
当我们谈论微服务时，一个常见问题是它是否仅仅是十年前我们看到的面向服务的架构(SOA)。这一点是有可取之处的，因为微服务风格和SOA赞同的某些主张十分相似。然而，问题是SOA意味着很多不同的东西，而大多数时候，我们遇到的所谓的SOA和这里我们描述的风格明显不同，这种不同通常由于SOA专注于用于集成单体应用的ESB。
特别是我们已看到太多的搞砸的服务导向的实现，从趋向于隐藏ESB中的复杂性[7]，到花费数百万并不产生任何价值的失败的多年举措，到积极抑制变化的集中治理模型，这有时很难看到过去的这些问题。
当然，微服务社区用到的许多技术从开发者在大型组织机构整合服务的经验中成长。Tolerant Reader模式就是这样的一个例子。使用简单协议是衍生自这些经验的另一个方法，使用网络的努力已做出远离中央标准的反应，坦率地说，中心标准已达到令人叹为观止的复杂性。(任何时候，你需要一个本体来管理你的本体，你知道你深陷困境。)
SOA的这种常见表现使得一些微服务倡导者完全拒绝SOA标签，尽管其他人认为微服务时SOA的一种形式[8]，也许服务导向做得对。无论哪种方式，事实上，SOA意味着如此不同的事情，这意味着有一个术语来更清晰地定义这种架构风格是有价值的。
Netflix是遵守这一理念的很好的例子。尤其是，以库的形式分享有用的且经过市场检验的代码，这激励其他开发者用类似的方式解决相似的问题，同时还为采用不同方法敞开了大门。共享库倾向于聚焦在数据存储、进程间通信和我们接下来要深入讨论的基础设施自动化的共性问题。
对为服务社区来说，开销特别缺乏吸引力。这并不是说社区不重视服务合约。恰恰相反，因为他们有更多的合约。只是他们正在寻找不同的方式来管理这些合约。像Tolerant Reader和消费者驱动的契约(Consumer-Driven Contracts)这样的模式通常被用于微服务。
这些援助服务合约在独立进化。执行消费者驱动的合约作为构建的一部分，增加了信心并对服务是否在运作提供了更快的反馈。事实上，我们知道澳大利亚的一个团队用消费者驱动的合约这种模式来驱动新业务的构建。他们使用简单的工具定义服务的合约。这已变成自动构建的一部分，即使新服务的代码还没写。服务仅在满足合约的时候才被创建出来 - 这是在构建新软件时避免"YAGNI"[9]困境的一个优雅的方法。围绕这些成长起来的技术和工具，通过减少服务间的临时耦合，限制了中心合约管理的需要。
侧边栏：许多语言，许多选项
JVM作为平台的成长就是在一个共同平台内混合语言的最新例子。几十年来，破壳到高级语言利用高层次抽象的优势已成为一种普遍的做法。如同下拉到机器硬件，用低层次语言写性能敏感的代码一样。然而，很多单体不需要这个级别的性能优化和常见的更高层次的抽象，也不是DSL的。相反，单体通常是单一语言的并趋向于限制使用的技术的数量[10]。
也许去中心化治理的最高境界就是亚马逊广为流传的build it/run it理念。团队要对他们构建的软件的各方面负责，包括7*24小时的运营。这一级别的责任下放绝对是不规范的，但我们看到越来越多的公司让开发团队负起更多责任。Netflix是采用这一理念的另一家公司[11]。每天凌晨3点被传呼机叫醒无疑是一个强有力的激励，使你在写代码时关注质量。这是关于尽可能远离传统的集中治理模式的一些想法。
去中心化数据管理
数据管理的去中心化有许多不同的呈现方式。在最抽象的层面上，这意味着使系统间存在差异的世界概念模型。在整合一个大型企业时，客户的销售视图将不同于支持视图，这是一个常见的问题。客户的销售视图中的一些事情可能不会出现在支持视图中。它们确实可能有不同的属性和(更坏的)共同属性，这些共同属性在语义上有微妙的不同。
这个问题常见于应用程序之间，但也可能发生在应用程序内部，尤其当应用程序被划分成分离的组件时。一个有用的思维方式是有界上下文(Bounded Context)内的领域驱动设计(Domain-Driven Design, DDD)理念。DDD把一个复杂域划分成多个有界的上下文，并且映射出它们之间的关系。这个过程对单体架构和微服务架构都是有用的，但在服务和上下文边界间有天然的相关性，边界有助于澄清和加强分离，就像业务能力部分描述的那样。
侧边栏：久经考验的标准和执行标准
这有一点分裂，微服务团队倾向于避开企业架构组规定的那种严格的执行标准，但又很乐意使用甚至传教开放标准，比如HTTP、ATOM和其他威格士。
关键的区别是如何定制标准和如何执行。由诸如IETF等组织管理的标准仅当在世界范围内有几个有用的实现时才变成标准，这往往会从成功的开源项目成长起来。
这些标准是远离企业世界的标准。往往被一个几乎没有近期编程经验的或受供应商过度影响的组织开发的。
和概念模型的去中心化决策一样，微服务也去中心化数据存储决策。虽然单体应用程序更喜欢单一的逻辑数据库做持久化存储，但企业往往倾向于一系列应用程序共用一个单一的数据库 - 这些决定是供应商授权许可的商业模式驱动的。微服务更倾向于让每个服务管理自己的数据库，或者同一数据库技术的不同实例，或完全不同的数据库系统 - 这就是所谓的混合持久化(Polyglot Persistence)。你可以在单体应用程序中使用混合持久化，但它更常出现在为服务里。
对跨微服务的数据来说，去中心化责任对管理升级有影响。处理更新的常用方法是在更新多个资源时使用事务来保证一致性。这个方法通常用在单体中。
像这样使用事务有助于一致性，但会产生显著地临时耦合，这在横跨多个服务时是有问题的。分布式事务是出了名的难以实现，因此微服务架构强调服务间的无事务协作，对一致性可能只是最后一致性和通过补偿操作处理问题有明确的认知。
对很多开发团队来说，选择用这样的方式管理不一致性是一个新的挑战，但这通常与业务实践相匹配。通常业务处理一定程度的不一致，以快速响应需求，同时有某些类型的逆转过程来处理错误。这种权衡是值得的，只要修复错误的代价小于更大一致性下损失业务的代价。
基础设施自动化
在过去的几年中，基础设施自动化已经发生了巨大的变化，特别是云和AWS的演化已经降低了构建、部署和运维微服务的操作复杂度。
许多用微服务构建的产品或系统是由在持续部署和它的前身持续集成有丰富经验的团队构建的。团队用这种方式构建软件，广泛使用了基础设施自动化。如下面的构建管线图所示：
图5: 基础构建管道
因为这不是一篇关于持续交付的文章，我们这里将之光住几个关键特性。我们希望有尽可能多的信心，我们的软件正在工作，所以我们运行大量的自动化测试。促进科工作软件沿管道线“向上”意味着我们自动化部署到每个新的环境中。
一个单体应用程序可以十分愉快地通过这些环境被构建、测试和推送。事实证明，一旦你为单体投入了自动化生产之路，那么部署更多的应用程序似乎也不会更可怕。请记住，持续部署的目标之一是使部署枯燥，所以无论是一个或三个应用程序，只要它的部署仍然枯燥就没关系[12]。
侧边栏：使它容易做正确的事情
我们发现，作为持续交付和持续部署的一个后果，增加自动化的一个副作用是创造有用的工具，以帮助开发人员和运营人员。用于创造人工制品、管理代码库、起立(standing up)简单服务或添加标准监控和日志记录的工具现在都是很常见的。web上最好的例子可能是Netflix的开源工具集，但也有其他我们广泛使用的工具，如Dropwizard。
我们看到团队使用大量的基础设施自动化的另一个领域是在生产环境中管理微服务时。与我们上面的断言(只要部署是枯燥的)相比，单体和微服务没有太大的差别，各运营场景可以明显不同。
图6: 模块部署常常不同
为失效设计
使用服务作为组件的一个结果是，应用程序需要被设计成能够容忍服务失效。任何服务调用都可能因为供应者不可用而失败，客户端必须尽可能优雅的应对这种失败。与单体应用设计相比这是一个劣势，因为它引入额外的复杂性来处理它。结果是，微服务团队不断反思服务失效如何影响用户体验。Netflix的Simian Army在工作日诱导服务甚至是数据中心故障来测试应用程序的弹性和监测。
在生产环境中的这种自动化测试足够给大多数运营团队那种不寒而栗，通常在结束一周的工作之前。这不是说单体风格不能够进行完善的监测设置，只是在我们的经验中比较少见。
侧边栏：断路器和产品就绪代码
断路器(Circuit Breaker)与其他模式如Bulkhead和Timeout出现在《Release it!》中。这些模式是被一起实现的，在构建通信应用程序时，它们是至关重要的。这篇Netflix博文很好的解释了使用这些模式的应用程序。
既然服务随时都可能失败，那么能够快速检测故障，如果可能的话，能自动恢复服务是很重要的。微服务应用程序投入大量比重来进行应用程序的实时监测，既检查构形要素(每秒多少次数据请求)，又检查业务相关指标(例如每分钟收到多少订单)。语义监测可以提供一套早期预警系统，触发开发团队跟进和调查。
这对微服务架构特别重要，因为微服务偏好编排和事件协作，这会带来突发行为。虽然很多专家称赞偶然涌现的价值，事实的真相是，突发行为有时可能是一件坏事请。监测对于快速发现不良突发行为是至关重要的，所以它可以被修复。
单体可以被构建成和微服务一样透明 - 事实上，它们应该是透明的。不同的是，你绝对需要知道在不同进程中运行的服务是否断开。对同一进程中的库来说，这种透明性是不大可能有用的。
侧边栏：同步调用被认为是有害的
任何时候，在服务间有大量的同步调用，你将遇到停机的乘法效应。简单地说，就是你的系统的停机时间编程各个组件停机时间的乘积。你面临一个选择，让你的调用变成异步或者管理停机时间。在www.guardian.co.uk，他们已在新平台实现了一个简单的规则 - 每个用户请求一个同步调用，而在Netflix，他们的平台API重设计成在API交换结构(fabric)建立异步性。
微服务团队希望看到为每个单独的服务设置的完善的监控和日志记录，比如控制面板上显示启动/关闭状态和各种各样的运营和业务相关指标。断路器状态、当前吞吐量和时延的详细信息是我们经常遇到的其他例子。
进化式设计
微服务从业者，通常有进化式设计背景并且把服务分解看做是进一步的工具，使应用程序开发者能够控制他们应用程序中的变更而不减缓变更。变更控制并不一定意味着变更的减少 - 用正确的态度和工具，你可以频繁、快速且控制良好的改变软件。
当你试图把软件系统组件化时，你就面临着如何划分成块的决策 - 我们决定分割我们的应用的原则是什么？组件的关键特性是独立的更换和升级的理念[13] - 这意味着我们要找到这样的点，我们可以想象重写组件而不影响其合作者。事实上很多微服务群组通过明确地预期许多服务将被废弃而不是长期演进来进一步找到这些点。
卫报网站是被设计和构建成单体应用程序的一个好例子，但它已向微服务方向演化。网站的核心仍是单体，但他们喜欢通过使用调用单体API构建的微服务添加新功能。这种方法对天然临时性的特性特别方便，比如处理体育赛事的专题页面。网站的这样一部分可以使用快速开发语言迅速的被放在一起，并且一旦赛事结束立即删除。在金融机构中，我们看到类似的方法，为一个市场机会添加新服务，并在几个月甚至几周后丢弃掉。
强调可替代性是模块设计更一般原则的一个特例，它是通过变更模式来驱动模块化的[14]。你想保持在同一模块中相同时间改变的事情。系统中很少变更的部分应该和正在经历大量扰动的部分放在不同的服务里。如果你发现你自己不断地一起改变两个服务，这是它们应该被合并的一个标志。
把组件放在服务中，为更细粒度的发布计划增加了一个机会。对单体来说，任何变更都需要完整构建和部署整个应用程序。而对微服务来说，你只需要重新部署你修改的服务。这可以简化和加速发布过程。坏处是，你必须担心一个服务的变化会阻断其消费者。传统的集成方法试图使用版本管理解决这个问题，但是微服务世界的偏好是只把版本管理作为最后的手段。我们可以避免大量的版本管理，通过把服务设计成对他们的提供者的变化尽可能的宽容。
微服务是未来吗？
我们写这篇文章的主要目的是讲解微服务的主要思想和原则。通过花时间做这件事情，我们清楚地认为微服务架构风格是一个重要的思想 - 它值得为企业应用程序认真考虑。我们最近用这种风格构建了一些系统，也知道别人用这种风格并赞成这种风格。
那些我们知道的以某种方式开拓这种架构风格的包括亚马逊，Netflix，卫报，英国政府数字服务部门，realestate.com.au，前锋和comparethemarket.com。2013年的会议电路中全是正向微服务类别转移的公司 - 包括Travis CI。此外还有大量的组织长期以来一直在做可归为微服务类别的事情，但是还没有使用这个名字。(这通常被称为SOA - 虽然，正如我们说过的，SOA有许多矛盾的形式。[15])
尽管有这些积极的经验，但是，我们并不认为我们确信微服务是软件架构的未来发展方向。虽然到目前为止，与单体应用程序相比，我们的经验是正面的，但我们意识到这样的事实，并没有经过足够的时间使我们做出充分的判断。
通常，你的架构决策的真正后果是在你做出这些决定的几年后才显现的。我们已经看到对模块化有强烈愿望的一个好团队用单体架构构建的项目，已经衰败了多年。很多人相信微服务是不太可能出现这种衰败的，因为服务界限是明确的，并且很难围绕它打补丁。然而，知道我们看到经过足够岁月的足够的系统，我们不能真正评估微服务架构有多么成熟。
人们当然有理由希望微服务时多么不成熟。在组件化中做任何努力，成功取决于软件在多大程度上适用于组件化。很难弄清楚组件边界在哪里。进化式设计承认获取正确边界的困难性和使它们易于重构的重要性。但当你的组件是带有远程通信的服务时，那么重构它比重构带有进程内库的服务难很多。跨服务边界移动代码是很困难的，任何接口变更都需要在参与者之间进行协调，需要添加向后兼容层，并且测试也变得更加复杂。
侧边栏：《构建微服务》
我们的同事Sam Newman花费2014年的大部分时间写了一本书，捕捉了我们构建微服务的经验。如果你想深入到这个话题中，这应该是你的下一步。
另一个问题是，如果组件不组成的干净利索，那么所有你做的是将复杂度从组件内部转移到组件之间的连接。不仅仅是把复杂性移到周围，它将复杂性移动到一个不太明确、难以控制的地方。在没有服务间的凌乱连接的情况下，当你在看一个小的、简单的组件内部时，你可以很容易的认为事情是更好的。
最后，有团队技能的因素。更熟练的团队倾向于采用新技术。但是对更熟练的团队更有效的一种技术不一定适合于不太熟练的团队。我们已经看到大量的例子，不太熟练的团队构建了凌乱的单体架构，但这需要时间去看当微服务发生这种凌乱时会发生什么。一个差的团队总是创建一个差的系统 - 很难讲在这个例子中微服务会减少这种凌乱还是使它更糟糕。
我们听到的一个合理的说法是，你不应该从微服务架构开始。相反，从单体开始，使它保持模块化，一旦单体成为问题时把它分解成微服务。(虽然这个建议是不理想的，因为一个好的进程内接口通常不是一个好的服务接口。)
所以我们怀着谨慎乐观的态度写了这篇文章。到目前为止，我们已经看到关于微服务风格足以觉得这是一条值得探索的路。我们不能肯定地说，我们将在哪里结束，但软件开发的挑战之一是，你只能基于目前能拿到手的不完善的信息作出决定。