云原生系列技术（三）：微服务技术

通过前两节介绍的《Docker 介绍及实战》 和《Docker 镜像详解》，我们已经了解并上手了容器技术。容器改变了我们对软件的认识，站在 Docker 的角度，软件就是容器的组合，而容器又是微服务的最佳载体，一台计算机同时运行多个容器，从而就能很轻松地模拟出复杂的微服务架构，这一节我们就谈谈微服务技术。

什么是微服务

一句话概括：微服务就是一些协同工作的小而自治的服务。

什么是微服务架构

提到架构，就感觉要装逼了，简单说下什么是架构：

架构就是整体与组件的抽象描述。架构的本质是通过抽象、分层、分治、和演化思维来解决复杂问题。

那么，什么是微服务架构呢？

微服务架构是对多个微服务的组织方式，以及服务之间通信、协同、管理等流程的描述。

如下图所示，一个很简单的微服务架构：

微服务解决什么问题

任何一种技术都是为了解决某些问题而出现的。

下面我们谈谈微服务的出现是为了解决哪些问题：

首先微服务是相对传统单体应用的，那么传统单体应用有哪些让人苦恼的烦心事：

1. 复杂度逐渐变高

随着代码量的增多，代码越来越臃肿，各个模块之间的区别比较模糊，逻辑变得混乱，复杂度逐渐变 高。

2.技术债务上升

维护代码的人比较多，人员流动遗留下来的坑也多，导致团队接手困难，每次修改代码都心惊胆战，修改一个bug极有可能带来各种隐含的缺陷。

3.调试、部署速度变慢

代码量非常庞大，导致编译、部署所花费的时间越来越多。

4.阻碍技术创新

团队对于新技术的渴望是不言而喻的，由于单体应用的模块之间千丝万缕的联系，代码量大，逻辑不够清晰，想重构又怕牵一发而动全身；之前所用的过时技术框架升级比较困难。

5.局限的弹性和扩展能力

单体应用作为一个强耦合的整体，无法根据业务功能伸缩，只能作为一个整体进行扩展，这就造成资源浪费，同时无法针对不同业务模块的特性进行有针对性的伸缩，比如计算密集型服务、IO密集型服务。
​
以上问题足以令你抓狂，单体应用的问题归根结底都是由于“过度肥胖“导致的，使用微服务技术一切迎刃而解。

看到这里，是不是发现你现在的系统或项目有类似问题，但又无从下手？下面我们谈谈怎么实践微服务。

怎么实践微服务

微服务改造或拆分不能一概而论，最好结合自己的实际情况，酌情参考下面的总结：

总体思路：

1. 基于业务进行拆分
2. 拆分后可独立部署且自治
3. 渐进式拆分，避免大规模改造

结合具体的实践有几点经验：

1. 新产品、新功能全部微服务化

对于新产品、新功能构建而言，使用微服务不会过多考虑同现有遗留系统的整合，比如不要求用同一技术框架，或者同一语言。完全可以选择最合适的框架和语言快速开发。同时也易于保持代码结构清晰以及制定团队规范。

2. 先分离数据库，后分离服务

对于原来的单体应用，先根据业务进行拆分，业务的拆分要先分离数据库，后分离服务。数据模型是否彻底分开，决定了微服务的边界功能是否彻底划清。相信有人经历或见过一些直接从服务分离而造成多次重构和返工的案例。

3. 遗留系统部分微服务化

对于无法修改的遗留系统，推荐在系统外面增加新的功能做成微服务，而不是直接修改原有系统，逐步实现对老系统遗留部分的替换。

4. 建立统一的日志规范

规范整个系统而非微服务的日志体系，采用标准的日志格式以便后续对日志进行收割、聚合检索，也便于从整体的视角分析，监控，查看系统。

5. 选择成熟的框架

避免重复造轮子，站在别人的头顶，尽量选择市面上成熟的开源技术框架进行支撑，比如Spring Cloud和Dubbo。

综上所述，微服务的实施注定不是一个简单的过程，是需要企业潜心积累、循序渐进的过程。企业需要根据不同的业务，不同的发展阶段，选择不同的实施策略，并在实施的过程中不断提高关键能力，并构建企业内部的微服务生态圈，才能享受到微服务架构带来的巨大价值。

总结

随着领域驱动设计、持续交付、按需虚拟化、基础设施自动化、小型自治团队、大型集群系统这些实践的流行，微服务应运而生。它并不是被发明出来的，而是从现实世界中总结出来的一种趋势或模式。

“科学每解决一个问题，都要引发十个新问题”。软件定义了一个无限美好的未来，却将人们拖入充满泥淖的现实。微服务解决了它该解决的问题，但又带来了新的问题，服务间通信变得复杂，运维成本大幅提高，下一节给大家分享《DevOps技术》，主要讲解怎么通过DevOps来高效管理软件的生命周期。