微服务演化史（4）

第四个阶段是微服务（Micro-Service Architecture）架构阶段。

互联网的应用，在技术上提出了一些高要求，如高可用、高可靠，高并发等。在业务上也提出了一些复杂要求，如快速响应需求，迭代反馈等。在互联网某些场景下，对于整体系统的某些构件的某一些特性有特殊的要求，这就必须要要针对系统的不同构件功能进行处理和隔离。互联网的需求变化快和用户群体庞大。如何从系统架构的角度出发，构建灵活、易扩展的系统，而且随着用户量的增加，如何保证系统的可伸缩性、高可用性，成为系统架构面临的挑战。传统IT单块架构系统是以表现层、逻辑层、数据层等进行架构分层。但随着用户需求个性化、产品生命周期变短、市场需求不稳定等因素的出现，这种分层架构面临着越来越多的挑战。因此，如何找到一种更有效的、更灵活、更适应当前互联网时代需求的系统架构方式，成为业界关注的焦点。

在理论上，SOA已经非常成熟了，但是苦于没有落地的手段和方式。微服务架构可以很好地弥补这个缺陷。微服务架构也是IT技术发展到一定阶段，顺应IT技术而出现一个软件架构体系，这些IT技术包括通讯技术、轻量级REST技术、容器技术的出现，轻量级通讯协议标准、服务注册中心、云服务平台等IT基础设施的完善，以及Paas云、Iaas云的普及等。当然，微服务架构也有软件工程和软件过程管理的要求，如极限开发，敏捷等开发方式，持续集成，持续交付，开发部署一体化（Devops）、服务治理技术的要求。实践中，一些有技术实力的企业开始做一些服务拆分和治理的尝试，Netflix从大约2009年开始，完全重新定义了它的应用程序开发和操作模型。2013年Docker诞生，解决了微服务部署的最后一公里问题。

2011年5月在威尼斯附近举办的一个软件设计师座谈会，“微服务”（microservice）这个词第一次被用来描述所看到的一种常见的软件架构风格，这些人中的许多人最近都在探索这种架构风格。2012年5月，同样的参与者决定将这种软件架构风格赋予最合适的名称——微服务（“Microservices”）。微服务这个名词才正式出现在IT行业。所以我们话题所涉及到的微服务是Microservices而不是microservice。

在这个过程中，2012年3月杰姆斯Lewis在一个案例研究提出了Microservices - Java, the Unix Way,。Joe Walnes、Dan North、Evan Bottcher和Graham Tackley将这种方法描述为“细粒度SOA”。Fred George是一个从事IT40多年，接触过70+编程语言，为多个行业提供敏捷、持续交付、DevOps等转型服务的咨询专家，他在2012年3月一次演讲中，他描述他和所在的团队是如何将100万行的传统J2EE程序，通过解耦、自动化验证等实践，逐渐分解成20多个5K行代码的小服务，又分解成200多个500行代码的服务的过程。他对微服务的定义是，微服务架构就是比SOA的服务要小一点，短一点的服务（英文原文：Micro(u)Services Architecture-small,shortlived services rather than SOA）。Netflix的云架构师Adrain Cockcroft，主导了Netflix从2009到2016年服务化拆分、从数据中心迁移到云平台、以及组织、流程、工具等的演进等。他对微服务的定义是：Loosely coupled serviceoriented architecture with bounded contexts.翻译过来就是松耦合并有上下文边界。其中两个核心点Loosely coupled和Bounded context。ThoughtWorks的资深技术专家Neal Ford，也是《卓有成效的程序员》作者，他对微服务架构的定义是“Microservices are thefirst post DevOps revolution architecture.”这是第一次将微服务和DevOps紧密关联起来的版本。Johannes Thones在其文献中提出了微服务是可独立部署、独立扩展、独立测试且具有单纯职责的一个小型应用程序。Dmitry Namiot在文献中明确将微服务认定为一种较新的软件架构模式，该架构模式适用于开发一系列小型独立服务：每个微服务拥有独立进程，可以使用不同的开发语言实现，且不同微服务之间使用轻量级的通信方式。

从理念到实践，从业务到技术，从思路到落地，所有这一切都是微服务出现的条件。这些因素包括有技术条件促进，有软件工程要求，也有理论依据支撑。最后，总结大师来进行了归纳，架构大师Martin Fowler与James Lewis在2014年共同提出稍微比较完整的微服务架构概念（注意，这里不是微服务概念，而是微服务架构概念），微服务架构风格是一种使用一套小服务来开发单个应用的方式途径，每个服务运行在自己的进程中，并使用轻量级机制通信，通常是HTTP API，这些服务基于业务能力构建，并能够通过自动化部署机制来独立部署，这些服务使用不同的编程语言书写，以及不同数据存储技术，并保持最低限度的集中式管理。所以，专家学者都说微服务其实并不是一个新概念，而且潜移默化地存在这几十年的IT发展过程中。只是现在清晰地、明确的、稍微规范地把这么一些概念很多地整合在一个概念上。

现阶段微服务已经如火如荼地应用到各个企业的系统中，对于用户层次而言，有资深用户，熟练用户，普通用户和初学者用户。对于应用者的角度，有从边缘非核心业务探索尝试新兴技术的温柔型的变革者，有企业核心业务系统在日常支撑中承受着巨大压力的业务倒逼型者，有只是旁敲侧击，零敲碎打的观望型探索者。

在技术层面上，有最初的项目型微服务软件，如Netflix项目，接着进入到开源的微服务框架平台，如Spring Cloud平台，然后进入到了运维型的微服务框架平台，如Kubernetes等。同时各种基于微服务应用的基础设施技术，自动化技术，开发平台，管理工具、运行框架，底层技术平台层出不穷，也逐步成熟起来。据说进行了微服务技术栈2.0时代，在基础设施层面上提出了服务网格，带来了服务智能自治模式，如所谓的挎斗。在云平台结合上，微服务与基于容器云的云原生架构很好在融合在一块。在微服务运行环境中，提出Serverless和Faas架构并在应用中进行推广等。在业务分析层面，以前的各种有一定深度但却被遗忘的建模分析和设计管理思想也活跃起来了，如领域驱动设计，CQRS架构、六边形架构、Clean架构等等。在应用实施层面上。CI/CD和DevOps是首先响应微服务应用带来的流程转变，接着组织、团队、人员、文化等都在影响并推进微服务应用的发展。如今这几个层面和领域，前进的步伐都没有停止，新技术、新产品、新业态的不断涌出，共同推进微服务向着更方便、更易用、低成本、高效率、高可靠、高稳定、高可运维的方向发展。

也许现在来讨论微服务历史还嫌过早，这仅仅是IT发展的一个小小的阶段。本文只是作为其中的参与者或是知情者做一个小节性的解释和说明。在微服务继续发展和前行中，我们还将会遇到了很多问题，面对很多障碍，同时也产生很多的迷惑，本文就是暴露微服务发展过程中出现的问题，然后去定义问题，分析问题，并能够在一定程度上解决问题。

（完）