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

*作者：周世杰

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

什么是微服务

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

什么是微服务架构

架构的本质是通过抽象、分层、分治、和演化思维来解决复杂问题。那么什么是微服务架构呢？微服务架构是对多个微服务的组织方式，以及服务之间通信、协同、管理等流程的描述。下图表示最简单的一个微服务架构：

微服务解决什么问题

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

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

首先微服务是相对传统单体应用应运而生，那么传统单体应用有哪些让人苦恼的烦心事：
1. 复杂度逐渐变高
随着代码量的增多，代码越来越臃肿，各个模块之间的区别比较模糊，逻辑变得混乱，复杂度逐渐变高。
2. 技术债务上升
应用系统出现bug后会有紧急补丁，而紧急补丁多了后又会影响系统的原有设计，可能导致后面的开发越来越难修改。
3. 调试、部署速度变慢
代码量非常庞大，导致编译、部署所花费的时间越来越多。
4. 技术创新受阻
团队对于新技术的渴望是不言而喻的，由于单体应用的模块之间千丝万缕的联系，代码量大，逻辑不够清晰，想重构又怕牵一发而动全身。
5. 弹性和扩展能力受限
单体应用作为一个强耦合的整体，无法根据业务功能伸缩，只能作为一个整体进行扩展，这就造成资源浪费，同时无法针对不同业务模块的特性进行有针对性的伸缩，比如计算密集型服务、IO密集型服务等。

单体应用的问题归根结底都是由于“过度肥胖“导致的，使用微服务技术一切迎刃而解。看到这里，是不是发现你现在的系统或项目有类似问题，但又无从下手？下面我们谈谈怎么实践微服务。

怎么实践微服务

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

总体思路：

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

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

1. 新产品、新功能全部微服务化
对于新产品、新功能构建而言，使用微服务不会过多考虑同现有遗留系统的整合，比如不要求用同一技术框架，或者同一语言。完全可以选择最合适的框架和语言快速开发。同时也易于保持代码结构清晰以及制定团队规范。
2. 先分离数据库，后分离服务
对于原来的单体应用，先根据业务进行拆分，业务的拆分要先分离数据库，后分离服务。数据模型是否彻底分开，决定了微服务的边界功能是否彻底划清。相信有人经历或见过一些直接从服务分离而造成多次重构和返工的案例。先分离数据库后分离服务过程如下图所示。

3. 老系统部分微服务化
对于已上线的老系统，推荐新增功能做成微服务，再逐步实现对老系统遗留部分的替换。
4. 建立统一的日志规范
规范整个系统而非微服务的日志体系，采用标准的日志格式以便后续对日志进行收割、聚合检索，也便于从整体的视角分析，监控，查看系统。
5. 选择成熟的框架
避免重复造轮子，站在别人的头顶，尽量选择市面上成熟的开源技术框架进行支撑，比如Spring Cloud和Dubbo。

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

总结

随着领域驱动设计、持续交付、按需虚拟化、基础设施自动化、小型自治团队、大型集群系统这些实践的流行，微服务应运而生。它并不是被发明出来的，而是从现实世界中总结出来的一种趋势或模式。
“科学每解决一个问题，都要引发十个新问题”。软件定义了一个无限美好的未来，却将人们拖入充满泥淖的现实。微服务解决了它该解决的问题，但又带来了新的问题，服务间通信变得复杂，运维成本大幅提高，下一节给大家分享《DevOps技术》，主要讲解如何通过DevOps来高效管理软件的生命周期。敬请期待！