企业架构 - 了解分布式

WHY

想要学习架构，离开分布式就像瘸了一条腿！

WHAT

架构演进故事线, 来自书籍《凤凰架构》

微机和远程调用

在 20 世纪 70 年代末期到 80 年代初，计算机科学刚经历了从以大型机为主向以微型机为主的蜕变

“尽管“调用远程方法”与“调用本地方法”只有两字之差，但若要兼顾简单、透明、性能、正确、鲁棒、一致等特点，两者的复杂度就完全不可同日而语了”

软件分布式

“UNIX DCE 中提出的分布式服务的设计主旨：“开发人员不必关心服务是远程还是本地，都能够透明地调用服务或者访问资源”。”

为了对大型的单体系统进行拆分，让每一个子系统都能独立地部署、运行、更新，开发者们尝试过很多种方案，这里列举三种较有代表性的架构模式，烟囱式架构，微内核架构，事件驱动架构

尽管 SOA 本身还属于抽象概念，而不是特指某一种具体的技术，但它比单体架构和前面所列举的三种架构模式的操作性更强，已经不能简单视为一种架构风格，而是一套软件设计的基础平台。

SOA 它拥有领导制定技术标准的组织 Open CSA；有清晰的软件设计的指导原则譬如服务的封装性、自治、松耦合、可重用、可组合、无状态，等等；明确了采用 SOAP 作为远程调用协议，依靠 SOAP 协议族（WSDL、UDDI 和 WS-*协议）来完成服务的发布、发现和治理；利用企业服务总线（Enterprise Service Bus，ESB）的消息管道来实现各个子系统之间的交互，令各服务在 ESB 的调度下无须相互依赖就能相互通信，实现了服务松耦合

尽管有 Sun 和 IBM 等一众巨头在背后力挺，EJB 仍然败于以 Spring、Hibernate 为代表的“草根框架”，可见一旦脱离人民群众，终究会淹没在群众的海洋之中，连信息技术也不曾例外

“微服务”一词并不是 Peter Rodgers 凭空创造出来的概念，它最初可以说是 SOA 发展时催生的产物，就如同 EJB 推广过程中催生了 Spring 和 Hibernate 那样，这一阶段的微服务是作为 SOA 的一种轻量化的补救方案而被提出的

微服务是一种通过多个小型服务组合来构建单个应用的架构风格，这些服务围绕业务能力而非特定的技术标准来构建。各个服务可以采用不同的编程语言、不同的数据存储技术，运行在不同的进程之中。服务采取轻量级的通信机制和自动化的部署机制实现通信与运维

微服务追求的是更加自由的架构风格，摒弃了几乎所有 SOA 里可以抛弃的约束和规定，提倡以“实践标准”代替“规范标准”。可是，如果没有了统一的规范和约束，以前 SOA 解决的那些分布式服务的问题，不也就一下子都重新出现了吗？

的确如此，对于服务的注册发现、跟踪治理、负载均衡、故障隔离、认证授权、伸缩扩展、传输通信、事务处理等问题，微服务中将不再有统一的解决方案

“在微服务时代，人们之所以选择在软件的代码层面而不是硬件的基础设施层面去解决这些分布式问题，很大程度上是因为由硬件构成的基础设施跟不上由软件构成的应用服务的灵活性的无奈之举。软件可以只使用键盘命令就拆分出不同的服务，只通过拷贝、启动就能够实现伸缩扩容服务，硬件难道就不可以通过键盘命令变出相应的应用服务器、负载均衡器、DNS 服务器、网络链路这些设施吗？”

硬件分布式

早期的容器只被简单地视为一种可快速启动的服务运行环境，目的是方便程序的分发部署，在这个阶段，针对单个应用进行封装的容器并未真正解决分布式架构问题。尽管 2014 年微服务开始崛起的时候，Docker Swarm（2013 年）和 Apache Mesos（2012 年）就已经存在，更早之前也出现了软件定义网络（Software-Defined Networking，SDN）、软件定义存储（Software-Defined Storage，SDS）等技术

但是，被业界广泛认可、普遍采用的通过虚拟化基础设施去解决分布式架构问题的开端，应该要从 2017 年 Kubernetes 取得容器战争的胜利开始算起

“未来 Kubernetes 将会成为服务器端的标准运行环境，如同现在的 Linux 系统；服务网格也将会成为微服务之间通信交互的主流模式，把“选择什么通信协议”“怎样调度流量”“如何认证授权”之类的技术问题隔离于程序代码之外，取代今天 Spring Cloud 全家桶中大部分组件的功能。微服务只需要考虑业务本身的逻辑，这才是最理想的智能终端解决方案。”

结论

“一旦虚拟化的硬件能够跟上软件的灵活性，那些与业务无关的技术性问题便有可能从软件层面剥离，悄无声息地在硬件基础设施之内解决，让软件得以只专注业务，真正围绕业务能力构建团队与产品。如此，DCE 中未能实现的“透明的分布式应用”成为可能，Martin Flower 设想的“凤凰服务器[1]”成为可能，Chad Fowler 提出的“不可变基础设施[2]”也成为可能。

从软件层面独立应对分布式架构所带来的各种问题，发展到应用代码与基础设施软、硬一体，合力应对架构问题，”

HOW

• 了解架构模式

• 微服务、微服务特性、微服务实践技术

• 虚拟化技术、docker、kubernetes

• 服务网络

Reference

• 《凤凰架构》书籍