微服务的九个核心的业务与技术特征 ################################ 第一: 围绕业务能力构建 ====================== * 围绕业务能力构建(Organized around Business Capabilities) 这个核心技术特征，再次强调了康威定律的重要性:: 它的意思是，有怎样的结构、规模和能力的团队，就会产生出对应结构、规模、能力的产品。 组织架构应为适应业务架构而调整:: 如果本应该归属同一个产品内的功能，被划分在了不同的团队当中，那就必然会产生大量的跨团队沟通协作， 而跨越团队边界，无论是在管理、沟通，还是在工作安排上，都会产生更高的成本。 高效的团队，自然会针对这个情况进行改进，而当团队和产品磨合调节稳定了之后，就会拥有一致的结构。 第二: 分散治理 ============== * 分散治理(Decentralized Governance) 这个技术特征，表达的是:: “谁家孩子谁来管”。 微服务对应的开发团队，有着直接对服务运行质量负责的责任，也应该有着不受外界干预，掌控服务各个方面的权力 微服务更加强调的是，在确实有必要进行技术异构的时候，一个开发团队应该能有选择 “不统一” 的权利。 第三: 通过服务来实现独立自治的组件 ================================== * 通过服务来实现独立自治的组件(Componentization via Services) 强调要通过 “服务”（Service）而不是 “类库”（Library）来构建组件:: 是因为类库是在编译期静态链接到程序中的，会通过本地调用来提供功能， 而服务是进程外组件，它是通过远程调用来提供功能的。 尽管远程服务有更高昂的调用成本，但这是为组件带来隔离与自治能力的必要代价。 第四: 产品化思维 ================ * 产品化思维（Products not Projects） 产品化思维的意思就是:: 我们要避免把软件研发看作是要去完成某种功能，而要把它当做是一种持续改进、提升的过程。 比如，我们不应该把运维看作就是运维团队的事，把开发看作就是开发团队的事。 开发团队应该为软件产品的整个生命周期负责。 开发者不仅应该知道软件是如何开发的，还应该知道它会如何运作、用户如何反馈，乃至售后支持工作是怎样进行的。 这里服务的用户，不一定是最终用户，也可能是消费这个服务的另外一个服务。 以前在单体的架构模式下:: 程序的规模决定了我们无法让全部的开发人员，都关注到一个完整的产品， 在组织中会有开发、运维、支持等细致分工的成员，他们只关注于自己的一块工作。 但在微服务下，我们可以让团队中的每一位成员，都具有产品化思维。 因为在 “2 Pizza Tems” 的团队规模下，每一个人都了解全过程是完全有可能实现的。 第五: 数据去中心化 ================== * 数据去中心化（Decentralized Data Management） 微服务这种架构模式也明确地提倡，数据应该按领域来分散管理、更新、维护和存储。 在单体服务中，通常一个系统的各个功能模块会使用同一个数据库，虽然这种中心化的存储确实天生就更容易避免一致性的问题，但是，同一个数据实体在不同服务的视角里，它的抽象形态往往也是不同的。 第六: 轻量级通讯机制 ==================== * 轻量级通讯机制（Smart Endpoints and Dumb Pipes） :: 这个弱管道（Dumb Pipes）机制，可以说几乎算是在直接指名道姓地反对 ESB、BPM 和 SOAP 等复杂的通讯机制。 如果服务需要『编码加工、业务规则转换、一致性、认证授权等』的某一种功能或能力， 那就应该在服务自己的 Endpoint（端点）上解决，而不是在通讯管道上一揽子处理。 微服务提倡的是类似于经典 Unix 过滤器那样，简单直接的通讯方式。比如说，RESTful 风格的通讯，在微服务中就是比较适合的。 第七: 容错性设计 ================ * 容错性设计（Design for Failure） 容错性设计，是指软件架构不再虚幻地追求服务永远稳定，而是接受服务总会出错的现实:: 这个技术特征要求，在微服务的设计中，有自动的机制能够对其依赖的服务进行快速故障检测， 在持续出错的时候进行隔离，在服务恢复的时候重新联通。 所以 “断路器” 这类设施，对实际生产环境的微服务来说，并不是可选的外围组件，而是一个必须的支撑点。 如果没有容错性的设计，系统很容易就会因为一两个服务的崩溃带来的雪崩效应而被淹没。 可靠系统完全可以由会出错的服务来组成，这是微服务最大的价值所在 第八: 演进式设计 ================ * 演进式设计（Evolutionary Design） 容错性设计承认服务会出错，而演进式设计则是承认服务会被报废淘汰:: 一个良好设计的服务，应该是能够报废的，而不是期望得到长久的发展。 如果一个系统中出现不可更改、无可替代的服务，这并不能说明这个服务有多么重要，反而是系统设计上脆弱的表现。 微服务带来的独立、自治，也是在反对这种脆弱性。 第九: 基础设施自动化 ==================== * 基础设施自动化（Infrastructure Automation） 由于微服务架构下，运维的服务数量比起单体架构来说，要有数量级的增长，所以使用微服务的团队，会更加依赖于基础设施的自动化。