Martin Fowler和James Lewis合写的文章“Microservices: a definition of this new architectural term”，这篇文章定义了现代微服务的概念：微服务是一种通过多个小型服务的组合，来构建单个应用的架构风格，这些服务会围绕业务能力而非特定的技术标准来构建。各个服务可以采用不同的编程语言、不同的数据存储技术、运行在不同的进程之中。服务会采取轻量级的通讯机制和自动化的部署机制，来实现通讯与运维。此为，作者还列举出了微服务的九个核心的业务与技术特征，借此来领悟微服务在团队、开发、运维等一系列研发过程中的核心思想。

    第一，围绕业务能力构建（Organized around Business Capabilities）
    这个核心技术特征，实际上再次强调了康威定律的重要性。它的意思是，有怎样的结构、规模和能力的团队，就会产生出对应结构、规模、能力的产品。这个结论不是某个团队、某个公司遇到的巧合，而是必然的演化结果。
    如果本应该归属同一个产品内的功能，被划分在了不同的团队当中，那就必然会产生大量的跨团队沟通协作，而跨越团队边界，无论是在管理、沟通，还是在工作安排上，都会产生更高的成本。高效的团队，自然会针对这个情况进行改进，而当团队和产品磨合调节稳定了之后，就会拥有一致的结构。

    第二，分散治理（Decentralized Governance）
    这个技术特征，表达的是“谁家孩子谁来管”。微服务对应的开发团队，有着直接对服务运行质量负责的责任，也应该有着不受外界干预，掌控服务各个方面的权力，可以选择与其他服务异构的技术来实现自己的服务。
    这一点在真正实践的时候，其实多少都会留点儿宽松的处理余地。因为大多数的公司都不会在某一个服务用Java，另一个用Python，下一个用Golang，而是通常都会统一主流语言，甚至会有统一的技术栈或专有的技术平台。
    微服务不提倡也并不反对这种“统一”，它只负责提供和维护基础技术栈的团队，有被各方依赖的觉悟，要有“经常被凌晨3点的闹钟吵醒”的心理准备就好。
    微服务更加强调的是，在确实有必要进行技术异构的时候，一个开发团队应该能有选择“不统一”的权利。比如说，我们不应该强迫用Node.js去开发报表页面；要做人工智能计算的时候，也可以选择用Python，等等。

    第三，通过服务来实现独立自治的组件（Componentization via Services）
    这里，Martin Fowler与James Lewis之所以强调要通过“服务”（Service）而不是“类库”（Library）来构建组件，是因为类库是在编译期静态链接到程序中的，会通过本地调用来提供功能，而服务是进程外组件，它是通过远程调用来提供功能的。

    第四，产品化思维（Products not Projects）
    产品化思维的意思就是，我们要避免把软件研发看作是要去完成某种功能，而要把它当做是一种持续改进、提升的过程。比如，我们不应该把运维看作就是运维团队的事，把开发看作就是开发团队的事。
    开发团队应该为软件产品的整个生命周期负责。开发者不仅应该知道软件是如何开发的，还应该知道它会如何运作、用户如何反馈，乃至售后支持工作是怎样进行的。这里服务的用户，不一定是最终用户，也可能是消费这个服务的另外一个服务。
    以前在单体的架构模式下，程序的规模决定了我们无法让全部的开发人员，都关注到一个完整的产品，在组织中会有开发、运维、支持等细致分工的成员，他们只关注于自己的一块工作。但在微服务下，我们可以让团队中的每一位成员，都具有产品化思维。因为在“2 Pizza Tems”的团队规模下，每一个人都了解全过程是完全有可能实现的。

    第五，数据去中心化（Decentralized Data Management）
    微服务这种架构模式也明确地提倡，数据应该按领域来分散管理、更新、维护和存储。
    在单体服务中，通常一个系统的各个功能模块会使用同一个数据库，虽然这种中心化的存储确实天生就更容易避免一致性的问题，但是，同一个数据实体在不同服务的视角里，它的抽象形态往往也是不同的。
    比如，Bookstore应用中的书本，在销售领域中关注的是价格，在仓储领域中关注的是库存数量，在商品展示领域中关注的是书籍的介绍信息。如果是作为中心化的存储，那么这里所有的领域，都必须修改和映射到同一个实体之中，就会导致不同的服务之间，可能会互相产生影响，从而丧失了各自的独立性。
    另外，尽管在分布式中，我们要想处理好一致性的问题也很困难，很多时候都没法使用传统的事务处理来保证不出现一致性问题。但是两害相权取其轻，一致性问题这些必要的代价是值得付出的。

    第六，轻量级通讯机制（Smart Endpoints and Dumb Pipes）
    这个弱管道（Dumb Pipes）机制，可以说几乎算是在直接指名道姓地反对ESB、BPM和SOAP等复杂的通讯机制。
    ESB可以处理消息的编码加工、业务规则转换等；BPM可以集中编排企业的业务服务；SOAP有几十个WS-协议族在处理事务、一致性、认证授权等一系列工作。这些构筑在通讯管道上的功能，也许在某个系统中的确有一部分服务是需要的，但对于另外更多的服务来说是强加进来的负担。
    *如果服务需要上面的某一种功能或能力，那就应该在服务自己的Endpoint（端点）上解决，而不是在通讯管道上一揽子处理。
    微服务提倡的是类似于经典Unix过滤器那样，简单直接的通讯方式。比如说，RESTful风格的通讯，在微服务中就是比较适合的。

    第七，容错性设计（Design for Failure）
    容错性设计，是指软件架构不再虚幻地追求服务永远稳定，而是接受服务总会出错的现实。
    这个技术特征要求，在微服务的设计中，有自动的机制能够对其依赖的服务进行快速故障检测，在持续出错的时候进行隔离，在服务恢复的时候重新联通。所以“断路器”这类设施，对实际生产环境的微服务来说，并不是可选的外围组件，而是一个必须的支撑点。如果没有容错性的设计，系统很容易就会因为一两个服务的崩溃带来的雪崩效应而被淹没。

    第八，演进式设计（Evolutionary Design）
    容错性设计承认服务会出错，而演进式设计则是承认服务会被报废淘汰。
    一个良好设计的服务，应该是能够报废的，而不是期望得到长久的发展。如果一个系统中出现不可更改、无可替代的服务，这并不能说明这个服务有多么重要，反而是系统设计上脆弱的表现。微服务带来的独立、自治，也是在反对这种脆弱性。

    第九，基础设施自动化（Infrastructure Automation）
    基础设施自动化，如CI/CD的长足发展，大大降低了构建、发布、运维工作的复杂性。
    由于微服务架构下，运维的服务数量比起单体架构来说，要有数量级的增长，所以使用微服务的团队，会更加依赖于基础设施的自动化。毕竟，人工是无法运维成百上千，乃至成千上万级别的服务的。