IBM高级架构师结合多线程和Socket，深入实战微服务架构

前言

微服务架构的概念，现在对于大家应该都不陌生，无论使用 Apache Dubbo、还是 Spring Cloud，都可以去尝试微服务，把复杂而庞大的业务系统拆分成一些更小粒度且独立部署的 Rest 服务。但是你了解微服务的发展背景吗？接下来，咱们一块深入微服务的发展背景，也帮大家夯实一下微服务架构的技术发展。

 

面向服务的架构

1996年，Gartner 公司首次提出了面向服务的架构(Service-Oriented Architecture, SOA)这一软件设计思想。 其核心理念是将一个个的业务功能包装成一个个的标准服务， 为这些服务定义良好的接口和服务契约，以便在需要的时候可以重用和水平伸缩。通过将这些服务进行组合和编排，可以创建新的业务流程，或者灵活地修改现有流程，以适应不断变化的业务需求，让我们的系统功能更丰富、结构更灵活、更易于扩展。同时，让系统规模能够根据需要弹性伸缩，最大限度地利用现有资产，提高效率，降低成本。总之，要使我们的系统能更灵活、更快地响应不断变化的需求。

不过，受到当时计算机水平的限制，面向服务的架构思想在诞生之初，并没有得到广泛的关注和发展。随着软件系统的规模越来越大、越来越复杂，软件系统的架构也在不断地演进，

面向服务的架构开始受到人们的关注和认可。目前，大型软件系统的服务端架构多数都是面向服务的架构，或者正在朝这一架构迁移。要明确的是，面向服务的架构中的“服务”虽然也包括系统对外提供的服务，但更多的是指系统内部的各个“模块”或“组件”的“服务化”，以及模块(服务)之间的相互调用与协同。它是“分布式”与“服务化”两个技术发展趋势合流的产物。

分布式系统

所谓的“分布式”是相对于“集中式”的一种应用系统内部组织结构。相对于传统的集中式系统(单机应用系统和集群式应用系统都属于集中式系统)，分布式系统将原本集中在一个服务端应用中的功能模块拆分出来，分为多个系统组件或应用，分散部署在多个服务器上，并通过网络将它们连接起来协同工作。而客户端系统感觉不到服务端系统内部的这种变化，仍然和原来调用集中式系统一样。

分布式设计使得原本集中在单个服务器上进行的计算或存储需求被分散到了多个服务器上，从而降低了我们对单- -服务器的性能要求。这样就让我们能用相对廉价的PC服务器代替昂贵的传统服务器，并通过水平扩容的方式继续提升系统的处理能力。

分布式系统并没有约定其内部的各个组件或应用之间应采用什么样的形式来实现彼此通信。早期人们使用DCOM、CORBA等技术实现组件的暴露和远程访问。这便是分布式系统的早期形态。但是这些技术比较复杂且十分笨重，只在大型系统和企业级应用中被使用。尽管之后又出现了COM+、RMI、EJB 等技术，但仍然比较笨重和难用。

 

服务化

早期的系统都是相互独立的。受限于计算机的处理能力，其规模都比较小。比如，财务系统和人力资源管理系统分别是两个不同的系统。它们可能由不同的软件厂商，采用不同的开发语言和技术开发，并运行在各式各样的操作系统和硬件设备上。随着企业发展的需要，人们试着在两个系统间建立通信，尝试让它们彼此协同。双方的通信方式和协议由厂商之间彼此协商来制定，开发起来成本很高。各个厂商都试图制定自己的通信技术标准和协议，并力争成为业内标准。显然，如果所有厂商都遵循同一套技术标准和通信协议，就能大大地降低开发成本，让各个系统彼此更容易地互联互通。

随着基于Web的应用的普及，以及XML技术的出现和成熟，出现了基于HTTP、XML的服务暴露与远程访问方式，这就是Web Services.但Web Services 的协议和实现方式很多，技术标准也多种多样。企业内部各系统之间的互联互通仍然比较麻烦。于是，企业服务总线(Enterprise Service Bus，ESB) 系统被设计来实现各系统之间的服务接口适配和管理，以便各系统能够用自己熟悉的技术、标准和规范来相互调用彼此的服务。随着时间的推移，简单对象访问协议( Simple Object Acess Protocol, SOAP)、 Web服务描述语言( Web Services Description Language, WSDL)， 以及通用描述、发现与集成服务(Universal Description, Discovery and Integration，UDDI) 协议逐渐成为主流的Web Services 标准和规范。

后来，随着互联网技术的发展，基于HTTP RESTful的轻量级Web Services 逐渐取代了基于SOAP的传统WebServices技术成为主流。由于HTTPRESTful服务暴露和调用开销比SOAP小很多，且速度更快，这就使得我们可在大型系统内部也大量使用，以作为各子系统之间，尤其是异构子系