摘要：
- 微服务是什么，是
点？ - 微服务化是什么，是
线？ - 微服务架构是什么，是
面？ 难道它们三者之间就是点-线-面这样简单的关系？
可能你觉得这很扯吧，开始我也觉得这样描述不够恰当，但是后面思来想去，点-线-面简单且形象生动地说明这三者的概念及关系，也有助于读者理解和消化。
不烦请您仔细往下阅读，看看是不是这个理儿。
1. 微服务 - 点
从单体应用服务，到面向 SOA（Service-Oriented Architecture）服务，再到今天我们聊的微服务都是一样的，是对外提供服务的。
它们之间的区别：
在于服务体积（功能 / 模块）的大小，可能这里描述的不是很准确，但是意思差不多，依次是 Micro Server < SOA Server < Single Server。
因此，微服务强调的是服务的大小，形象的说就是一个点。而点也是有大小之分的。下面我们用图来展示三者的关系：
2. 微服务化 - 线
微服务化，这明显是向服务大小更小的服务演化，即系统从单体系统架构或面向SOA系统架构逐步向微服务架构演化的过程。
为什么要微服务化，这种架构演进的意义何在？
2.1 首先，我们来说一说，传统单体应用架构 以 JavaWeb 应用为例，传统的电商项目编译打包成一个 War 包，然后通过 Web 容器部署，比如部署在装有 Tomcat 或 Weblogic 的服务器上运行，通过 Nginx 或 Apache 做负载均衡，使得应用服务器达到集群部署的目的。架构图一般如下图所示：
这种框架结构虽然简单，但是随着时间不断的推移，系统的功能越来越复杂，就会产生一系列问题，如下所示：
- 系统复杂度增高 系统从简单的用户管理功能起步，随着需求不断的增多，系统开发越来越复杂，动一发而牵全身，业务模块与模块之间功能或是表结构交叉，导致系统二次开发复杂度提高。
- 可伸缩性差 单体架构系统由于单进程的局限性，水平扩展时只能基于整个系统进行扩展，无法针对某一个功能模块按需扩展。例如：电商系统，包含了 用户、商品、订单、交易、支付；如果商品的访问量非常大，我想对商品进行集群部署，这时你是无法做到，你只能对整个系统进行集群部署。
- 团队协作低效 整个系统一个团队。如果系统变得庞大，成员就需要学习大量的代码和领域知识，团队内的沟通和协作也变得低效。
- 可靠性差 比如线上某个功能的某一点出现了一个 bug，由于后端服务没有做必要参数校验而导致系统查询数据库表所有数据发生 OOM 或程序的死循环，导致整个系统进程宕机，也就意味着线上应用无法对外提供服务，影响用户使用其他模块功能等。
- 系统迭代困难 由于所有的功能都在一个系统里面，会导致日常迭代相当困难，例如互联网项目，多个项目每周一次小迭代，每月一次大的更新迭代，必定导致代码分支过多，分支合并代码繁琐困难。
- 技术更新慢 更新一个技术或是组件，在以前的架构上系统不合理，导致了整体系统一起重构的风险。
- 跨语言程度 整个系统（甚至整个企业）统一的技术栈，管理起来看似简单。但有时候统一的标准并不适合所有的实际情况。
- 测试、部署成本高 业务运行在一个进程中，因此系统中任何程序的改变，都需要对整个系统重新全局测试并部署，时间成本提高。
以上只是总结了单体应用的一部分问题。随着单体系统越来越大，越来越复杂，用户量指数级增长，系统可能会暴露出更多的问题，到那个时间就没有时间给你重构了，因为在你进行系统重构的时期，你的用户已经开始逐步流失。所以架构师和需求人员必须提前预估线上业务和用户的增长，提前做好进行系统架构重构的准备工作。
那么如何解决以上的问题呢？
2.2 架构演化 —— SOA
很早之前互联网企业都引入了面向服务架构（SOA）体系，比如电商、银行、保险等金融企业，在早期为了快速解决单体应用架构的缺点，开始将单体系统架构慢慢迁移到 SOA 架构（2000开始火起来）。
SOA 架构突出强调服务化，但是它是一种粗粒度、松耦合服务架构。SOA 服务架构示意图如下：
SOA 架构的一些优点。
- 大的传统单体应用系统拆分成各个子系统。多团队开发或维护各自子系统，开发互不影响，效率得到提高。
- 接口的发布和管理集中。服务接口通过 ESB 企业服务总线管理，一致对外或其他子系统提供接口服务，使得各个系统之间解耦。
- 子系统升级便捷。无须考虑是否影响其他子系统。
- 各子系统升级或部署也更简单快捷。无须考虑是否影响其他子系统。
- 技术迭代也互不影响。无须考虑是否影响其他子系统。
虽然 SOA 的优点很多，也解决了传统单体应用架构的部分问题，但是各个子系统还是比较大，不利于开发维护。为了解决 SOA 架构的不足，怎么办呢。
2.3 架构再演化——微服务架构
将应用划分为粒度更小且能相互通信的微服务。随着不断地实践，微服务架构思维就出现了。由此演变的最简单的微服务架构图如下所示：
微服务架构的优点：
- 技术选型灵活
- 扩展性强
- 系统复杂度可控
- 功能模块更小更专
- 容易维护
- 独立部署
微服务架构目前也有很多不足之处，比如：
- 开发人员开发或维护多个微服务，需要启动多个微服务，增加本地测试的难度。
- 需要了解各个微服务之间的通信及与其他第三方系统的通信机制。
- 跨微服务之间的调用，需要掌握分布式事务处理机制。
- 微服务之间的联调增加了开发人员的沟通成本。
- 日志的采集和集中管理复杂，需要开发人员了解一些相关中间件技术，增加开发人员的学习成本。
- 部署和测试也很复杂，需要了解持续集成的框架或自动化测试技术，增加开发人员的学习成本。
- 系统资源浪费严重，需要了解容器技术，增加开发人员的学习成本。
- 系统及使用的中间件的监控复杂。
- 系统调优和查错难度更高。 等等。。。
所以，从以上关于微服务架构优缺点的分析，发现微服务也不是那么的简单，也不是万能的吧。可能对于从事微服务的开发人员，分配的需求开发任务很简单，其实涉及的技术和架构设计能力要求更高。总之一句话，从传统应用的单体架构或是 SOA 架构转向微服务架构，得确保你有能力 hold 住。小心搬起石头砸了自己的脚！
综上所述，没有万能的系统架构，只有最适合你的系统架构设计。可能 n 年之后，微服务架构已经无法满足你的业务场景，又会衍生出一种新的架构设计，因此随着时间的推移必然会发生系统架构演化，而这一切关于系统架构演化的目的也是为了更好的服务我们，哈哈?。
3. 微服务架构 - 面
微服务架构其实就是一种架构思想或是架构风格。
将系统按功能模块划分成细粒度的微服务（未运行的微服务工程），每一个微服务实例（正常运行的微服务，每个微服务可以启动多个实例）都可以独立的对外提供 REST API 接口服务。前后端分离模式也在微服务架构中运用的淋漓尽致。所以，前后端架构设计都可以使用微服务架构思想，以极大的提升系统性能。
通过以上关于微服务和微服务化的细致解读，由点到线再到面，我们可以总结出传统单体架构演变成微服务架构的解决方案如下：
拆分：对应用按业务功能模块进行水平和垂直拆分，例如用户中心、商品中心、订单中心等。解耦：通过服务化、订阅和发布机制对应用调用关系解耦，支持服务的自动注册和发现。透明：通过服务注册中心管理服务的发布和消费、调用关系。独立：服务可以独立打包、发布、部署、启停、扩容和升级，核心服务独立集群部署。分层：梳理和抽取核心应用、公共应用，作为独立的服务下沉到核心和公共能力层，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。
根据以上解决方案，可以了解现在流行的微服务架构的是如何构建的，大致步骤如下：
- 首先就是微服务的拆分
- 按业务功能模块划分
- 按领域驱动设计划分
- 按操作资源划分
- 微服务架构的组件及技术选型
- 注册中心（服务的注册与发现，Eureka、Zookeeper、Nacos、Dubbo、Consul、Etcd等）
- 负载均衡（服务消费者找到合适的服务提供者，Dubbo、Spring Cloud Ribbon）
- 服务容错（实现服务保护机制，Spring Cloud Hystrix）
- 网关（服务代理层，鉴权、限流、路由、灰度等，Spring Cloud Zuul、Spring Cloud Gateway）
- 配置中心（集中管理和维护配置文件信息，Spring Cloud Config、Apollo、Nacos）
- 在线接口（方便生成接口文档和接口测试，Swagger）
- 日志框架（方式日志收集和展示，ELK框架）
- 持续集成（通过 Docker 打包微服务镜像，利用 Jenkins 自动化启动容器，部署微服务）
- 链路追踪与监控（服务之间调用链追踪，Spring cloud sleuth Zipkin，Pinpoint、Skywalking） 以上大部分是 Spring Cloud 组件。
- 微服务架构的基本框架设计
4. 小结
由微服务（点）到微服务化（线），再到微服务架构（面），从不同角度和维度分析了微服务的优缺点，也间接说明了为什么微服务现在很流行。但是微服务不一定适合所有的互联网企业，需要架构师们根据自己的业务和应用场景去斟酌到底使用什么架构更合适。因为将自己的系统重构成微服务架构也面临着巨大的挑战——人力成本、技术成本、硬件成本、运维成本等等。
