简而言之，微服务架构风格[1]这种开发方法，是以开发一组小型服务的方式来开发一个独立的应用系统的。其中每个小型服务都运行在自己的进程中，并经常采用HTTP资源API这样轻量的机制来相互通信。这些服务围绕业务功能进行构建，并能通过全自动的部署机制来进行独立部署。这些微服务可以使用不同的语言来编写，并且可以使用不同的数据存储技术。对这些微服务我们仅做最低限度的集中管理。
一个组件就是一个可以独立更换和升级的软件单元。
微服务架构也会使用软件库，但其将自身软件进行组件化的主要方法是将软件分解为诸多服务。我们将软件库(libraries)定义为这样的组件，即它能被链接到一段程序，且能通过内存中的函数来进行调用。然而，服务(services)是进程外的组件，它们通过诸如web service请求或远程过程调用这样的机制来进行通信（这不同于许多面向对象的程序中的service object概念
任何设计（广义上的）系统的组织，都会产生这样一个设计，即该设计的结构与该组织的沟通结构相一致。
? ——梅尔文?康威（Melvyn Conway）, 1967年
微服务使用不同的方法来分解系统，即根据业务功能（business capability）来将系统分解为若干服务。这些服务针对该业务领域提供多层次广泛的软件实现，包括用户界面、持久性存储以及任何对外的协作性操作。因此，团队是跨职能的，它拥有软件开发所需的全方位的技能：用户体验、数据库和项目管理。
通常认为这一点源自亚马逊的“谁构建，谁运行”的理念，即一个开发团队对一个在生产环境下运行的软件负全责。这会使开发人员每天都会关注软件是如何在生产环境下运行的，并且增进他们与用户的联系，因为他们必须承担某些支持工作。
这样的“产品”理念，是与业务功能的联动绑定在一起的。它不会将软件看作是一个待完成的功能集合，而是认为存在这样一个持续的关系，即软件如何能助其客户来持续增进业务功能。
微服务社区主张采用另一种做法：智能端点(smart endpoints)和傻瓜管道(dumb pipes)。使用微服务所构建的各个应用的目标，都是尽可能地实现“高内聚和低耦合”——他们拥有自己的领域逻辑，并且更多地是像经典Unix的“过滤器”(filter)那样来工作——即接收一个请求，酌情对其应用业务逻辑，并产生一个响应。这些应用通过使用一些简单的REST风格的协议来进行编制，而不去使用诸如下面这些复杂的协议，即"WS-编制"(WS-Choreography)、BPEL或通过位于中心的工具来进行编排(orchestration)。
相比选用业界一般常用的技术，构建微服务的那些团队更喜欢采用不同的方法。与其选用一组写在纸上已经定义好的标准，他们更喜欢编写一些有用的工具，来让其他开发者能够使用，以便解决那些和他们所面临的问题相似的问题。这些工具通常源自他们的微服务实施过程，并且被分享到更大规模的组织中，这种分享有时会使用内部开源的模式来进行。现在，git和github已经成为事实上的首选版本控制系统。在企业内部，开源的做法正在变得越来越普遍。
微服务更喜欢让每一个服务来管理其自有数据库。其实现可以采用相同数据库技术的不同数据库实例，也可以采用完全不同的数据库系统。这种方法被称作“多语种持久化”(Polyglot Persistence）
为了尽可能地获得对正在运行的软件的信心，需要运行大量的自动化测试。让可工作的软件达到“晋级”(Promotion)状态从而“推上”流水线，就意味着可以在每一个新的环境中，对软件进行自动化部署。
我们所看到的各个团队在广泛使用基础设施自动化实践的另一个领域，是在生产环境中管理各个微服务。与前面我们对比单块系统和微服务所说的正相反，只要部署工作很无聊，那么在这一点上单块系统和微服务就没什么区别。然而，两者在运维领域的情况却截然不同。
因为各个服务可以在任何时候发生故障，所以下面两件事就变得很重要，即能够快速地检测出故障，而且在可能的情况下能够自动恢复服务。各个微服务的应用都将大量的精力放到了应用程序的实时监控上，来检查“架构元素指标”（例如数据库每秒收到多少请求）和“业务相关指标”（例如系统每分钟收到多少订单）。当系统某个地方出现问题，语义监控系统能提供一个预警，来触发开发团队进行后续的跟进和调查工作。
这对于一个微服务架构是尤其重要的，因为微服务对于服务编制(choreography)和事件协作(http://martinfowler.com/eaaDev/EventCollaboration.html)的偏好，会导致“突发行为”。尽管许多权威人士对于偶发事件的价值持积极态度，但事实上，“突发行为”有时是一件坏事。在能够快速发现有坏处的“突发行为”并进行修复的方面，监控是至关重要的。
那些微服务团队希望在每一个单独的服务中，都能看到先进的监控和日志记录装置。例如显示“运行/宕机”状态的仪表盘，和各种运维和业务相关的指标。另外我们经常在工作中会碰到这样一些细节，即断路器的状态、当前的吞吐率和延迟，以及其他一些例子。
一个组件的关键属性，是具有独立更换和升级的特点——这意味着，需要寻找这些点，即想象着能否在其中一个点上重写该组件，而无须影响该组件的其他合作组件。事实上，许多做微服务的团队会更进一步，他们明确地预期许多服务将来会报废，而不是守着这些服务做长期演进。
这种强调可更换性的特点，是模块化设计一般性原则的一个特例，通过“变化模式”(pattern of change)来驱动进行模块化的实现。大家都愿意将那些能在同时发生变化的东西，放到同一个模块中。系统中那些很少发生变化的部分，应该被放到不同的服务中，以区别于那些当前正在经历大量变动(churn)的部分。如果发现需要同时反复变更两个服务时，这就是它们两个需要被合并的一个信号。
有人觉得微服务或许很难成熟起来，这当然是有原因的。在组件化上所做的任何工作的成功与否，取决于软件与组件的匹配程度。准确地搞清楚某个组件的边界的位置应该出现在哪里，是一件困难的工作。演进式设计承认难以对边界进行正确定位，所以它将工作的重点放到了易于对边界进行重构之上。但是当各个组件成为各个进行远程通信的服务后，比起在单一进程内进行各个软件库之间的调用，此时的重构就变得更加困难。跨越服务边界的代码移动就变得困难起来。接口的任何变化，都需要在其各个参与者之间进行协调。向后兼容的层次也需要被添加进来。测试也会变得更加复杂。
另一个问题是，如果这些组件不能干净利落地组合成一个系统，那么所做的一切工作，仅仅是将组件内的复杂性转移到组件之间的连接之上。这样做的后果，不仅仅是将复杂性搬了家，它还将复杂性转移到那些不再明确且难以控制的边界之上。当在观察一个小型且简单的组件内部时，人们很容易觉得事情已经变得更好了，然而他们却忽视了服务之间杂乱的连接。
最后，还有一个团队技能的因素。新技术往往会被技术更加过硬的团队所采用。对于技术更加过硬的团队而更有效的一项技术，不一定适用于一个技术略逊一筹的团队。我们已经看到大量这样的案例，那些技术略逊一筹的团队构建出了杂乱的单块架构。当这种杂乱发生到微服务身上时，会出现什么情况？这需要花时间来观察。一个糟糕的团队，总会构建一个糟糕的系统——在这种情况下，很难讲微服务究竟是减少了杂乱，还是让事情变得更糟。
原文：https://www.cnblogs.com/y6ming/p/13941320.html