服务端指南 服务端概述 | 微服务架构概述

原文地址：微服务架构概述
博客地址：blog.720ui.com/

传统的单体架构，使用三层架构，包括视图表现层、业务逻辑层与数据访问层，其划分的目的是为了更好地规划软件系统的逻辑结构，便于开发与维护。单体架构将整个应用系统视为一个总体，部署在同一个 Web 容器。例如，一个 VR 资讯系统包含资讯模块、话题模块、日报模块、百科模块等多个模块，在单体架构中，全部的功能模块都在同一个应用系统中，而且共同使用一个数据库。

单体架构的好处在于，全部的功能模块都在同一个应用系统中，很是容易开发与测试。可是，随着系统规模的不断扩大，业务需求的不断迭代，系统功能的持续增长，传统的单体架构面对的问题也愈来愈多，主要体如今几个方面：

• 开发效率变低。全部的功能模块都在同一个应用系统中，团队成员须要共同维护同一套工程代码，势必增长了相应的沟通成本与协做成本。
• 维护成本增长。业务需求的不断迭代与系统功能的持续增长，使得这个应用系统变得愈来愈庞大，愈来愈复杂。一方面，开发人员在开发功能与修复缺陷的成本变高，另外一方面，新加入团队的成员也须要花费巨大的精力去熟悉这个巨无霸的业务系统。
• 部署影响变大。系统规模的不断扩大，带来的另一个后果就是构建时间变长。每次新功能版本发布，或修复缺陷从新部署，这个过程将致使应用系统不可用，至关于系统宕机，影响面较大。
• 可扩展性较差。应用系统做为一个业务强耦合的总体，不管是水平扩展仍是垂直扩展，都存在扩展性问题。
• 技术选型成本高。单体架构技术选型相对而言比较单一，很难平滑替换新的技术。

随着敏捷开发、持续交付、虚拟化技术、DevOps 理论的实践，微服务架构应运而生，并逐渐使得应用架构朝着高可用性、可扩展性、可伸缩性发展的方向演进。ThoughtWorks 公司的首席科学家 Martin Fowler 对微服务进行了描述，他说到：“微服务是一种将单个应用划分红许多小的服务来构建软件的架构模式。每一个服务运行在本身的进程中，服务与服务间采用轻量级的通讯机制互相沟通（一般是基于 HTTP 协议的 RESTful API）。每一个服务都围绕着具体业务和各自独立的自动化部署机制构建而来。每一个服务须要极少的集中管理，所以可使用不一样的编程语言以及不一样的存储技术。”。Martin Fowler 还列举了微服务的九个特征，包括经过服务实现组件化、围绕业务能力进行组织、基于产品而不是项目、智能端点与哑管道、去中心化治理、去中心化数据管理、基础设施自动化、为故障而生、演进的设计。若是对Martin Fowler 的微服务描述感兴趣，能够阅读 martinfowler.com/articles/mi…

请读者思考，微服务的拆分粒度多小，才能算是“微”?通常状况下，拆分粒度应该保证微服务具备业务的独立性与完整性，所以微服务的拆分围绕业务模块进行拆分。那么，这里将 VR 资讯系统进行服务拆分，分为资讯系统、话题系统、日报系统、百科系统四个微服务系统，每一个微服务独立使用一个数据库。

微服务带来的价值，主要体如今几个方面：

• 每一个微服务易于开发和维护，便于沟通与协做，很适合小团队敏捷开发与持续交付。
• 每一个微服务职责单一，高内聚、低耦合。同时，每一个微服务可以独立开发、独立运行、独立部署。
• 每一个微服务之间是独立的，若是某个服务部署或者宕机，只会影响到当前服务，而不会对整个业务系统产生影响。
• 每一个微服务能够随着系统规模的不断扩大，面对海量用户和高并发，独立作水平扩展与垂直扩展。
• 每一个微服务可使用不一样的编程语言以及不一样的存储技术，使得咱们更容易尝试新的技术。此外，对单个服务进行业务重构，也不会面临很大的业务负担与技术债卷。

微服务不是银弹，它也带来了一些技术的复杂度。所以，咱们须要思考与解决分布式的复杂性、事务的一致性、服务的管理与运维、服务的自动化部署等解决方案。

总结下，随着系统规模的不断扩大，业务需求的不断迭代，系统功能的持续增长，传统的单体架构面对的问题也愈来愈多。而且互联网产品需求变化快、用户量大，传统的单体架构显得力不从心。而随着敏捷开发、持续交付、虚拟化技术、DevOps 理论的实践，微服务架构取代了传统的单体架构，将单个应用划分红许多小的服务，服务与服务间采用基于 HTTP 协议的 RESTful API 通讯。在收获微服务带来的价值的同时，须要解决微服务带来的一些技术的复杂度问题。

（完）

更多精彩文章，尽在「服务端思惟」微信公众号！