服务架构演变

读周志明老师《凤凰架构》有感。

单体架构

单体建构就是我们常写的单机应用。单体架构最核心的特点在于 架构内所有的通信都发生在同一个进程内。

这也意味着，对于一些简单的应用，单体架构是最合适的，不需要发生进程间的通信，可以共享部分数据等等。

但随着应用的规模变大，代码越来越复杂，单体架构就不太适合。

单体架构的问题不在于不可拆分上，实际上单体架构也是可以拆分成不同的模块，可以由多个jar包共同组成。

单体架构的核心问题在无法隔离和自治上。一旦某一部分代码出现了问题，将会影响整个系统！同时如果我们想要更新一部分代码，就必须重启整个系统，而不能重启1/4系统！

SOA

SOA其实是一种分布式的架构，SOA采用复杂的SOAP协议来完成服务之间的发现，治理，发布等，ESB（消息管道）实现各个服务之间的通信

微服务

微服务和SOA很像，现在也有人称微服务为SOA的变种。

微服务摒弃了SOA复杂的SOAP和ESB，希望开发人员在编写代码时不必考虑就是是微服务还是单机架构。

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

这也意味着，微服务没有统一的技术方案，技术选型组合很多。

微服务时代充满着自由的气息，微服务时代充斥着迷茫的选择。

后微服务（云原生）

分布式中的注册发现、跟踪治理、负载均衡、传输通信等为什么一定要用软件实现？这些其实都可以在硬件层面做到，譬如，某个系统需要伸缩扩容，通常会购买新的服务器，部署若干副本实例来分担压力；如果某个系统需要解决负载均衡问题，通常会布置负载均衡器，选择恰当的均衡算法来分流；如果需要解决传输安全问题，通常会布置 TLS 传输链路，配置好 CA 证书以保证通信不被窃听篡改；如果需要解决服务发现问题，通常会设置 DNS 服务器，让服务访问依赖稳定的记录名而不是易变的 IP 地址，等等。经过计算机科学多年的发展，这些问题大多有了专职化的基础设施去解决，而之所以微服务时代，人们选择在软件的代码层面而不是硬件的基础设施层面去解决这些分布式问题，很大程度上是因为由硬件构成的基础设施，跟不上由软件构成的应用服务的灵活性的无奈之举。软件可以只使用键盘命令就能拆分出不同的服务，只通过拷贝、启动就能够伸缩扩容服务，硬件难道就不可以通过敲键盘就变出相应的应用服务器、负载均衡器、DNS 服务器、网络链路这些设施吗？

正是虚拟化和容器化的出现，使得我们借助docker和k8s能够达到软件模拟硬件的效果。

但这也存在一个问题，容器的引入使得我们的粒度变粗，我们模拟的基础设施监管的粒度变为容器，而不是容器里的服务。

于是“服务网格”出现了

它的原理是在容器中自动注入一个代理，它会劫持服务之间的通信请求，由它来接受基础设施的管理，并发送请求给具体的服务。

在云原生时代，正是由于虚拟机的存在，java的镜像体积大（必须要下载整个虚拟机），启动时间慢（spring生态的依赖注入），内存消耗严重（jvm的存在导致java具有固定的内存消耗），这些都与云原生的思想相违背，所以有人说java不适合云原生时代。

无服务

无服务是单体架构的进化。

在云计算时代，云被认为是具有无限存储能力，无限计算能力。

于是有人觉得，开发人员应该专注业务代码，所有需要的组件比如mysql,redis都由云提供，负载均衡等都由云来做。