[toc]
服务架构演进史#
1 原始分布式时代#
DCE（Distributed Computing Enviroment）也就是分布式运算环境，是一种很经典原始的设计理念。
DCE的设计主旨：“开发人员不必关心服务是远程还是本地，都能够透明地调用服务或者访问资源”
是很早由OSF指定的分布式技术体系理论，解答了很多问题，例如：
- 远程服务在哪？——对应服务发现
- 要部署多少个？——对应负载均衡
- 请求超时怎么办？——对应熔断、隔离、降级
- 方法参数和结果如何表示？——对应序列化方式
- 信息如何传入？——对应传输协议选型
- 服务权限？——对应认证、授权方案
- 怎么保证不同机器间的状态最终一致？——对应分布式数据一致性
但最终发现解决这些问题的代价 远超 分布式所带来的收益，在DCE刚提出的年代（80年代），机器资源并没到那个程度, 于是暂时被搁置了。
2 单体系统#
单体系统并不一定就代表是坏的，不好的，需要综合分析：
单体架构的好处#
如果是相同资源的前提下， 单体系统的性能是比分布式要高的。
所有数据都是进程内通信
且开发、部署、测试都基于同一个对象进行处理，更加方便。
单体系统中的代码一般也是做好了分层、分模块的，也是易于敏捷开发和迭代的。
单体架构的坏处#
然而如果单体系统中一部分代码出现缺陷， 可能直接把进程空间耗光，或者直接打崩整个进程，也没有办法针对某个代码模块做单独的升级或者更新。
因此当系统规模较小的时候，单体系统有独特的优势。
系统规模越来越大， 则要求各功能模块能够自治和隔离，减少爆炸范围。
从“追求尽量不出错”到“追求出错是必然”，是微服务架构挑战并取代单体架构的底气所在。
3 SOA——面向服务架构#
SOA（Service-Oriented-Architecture），也叫做面向服务的架构。
它类似于各服务之间协议和通信方式高度一致性，各服务遵循完全相同的消息协议和管理机制
终极目标是总结出一套自上而下的软件研发方法论，最后新厂家要开发系统时，八股文一般照搬SOA架构和实现即可
有一种参考的SOA架构是事件驱动架构：
所有服务连接一个统一的消息管道，从管道中接收统一的事件消息和响应机制。
SOA最终落寞的原因：
- 过于严格的规范定义带来了过度的复杂性
- 过于精密的流程和理论需要懂得复杂概念的专业人员才能驾驭
4 微服务时代#
微服务的九个核心业务与技术特征#
- 围绕业务能力构建：根据业务划分细粒度的服务和团队
- 分散治理： 各服务、各团队对服务质量各自负责，不受其他服务影响，可以各自演进而不用统一规化
- 通过服务而不是类库来实现自治
- 产品化思维：各服务开发人员关注整个微服务的全方位生命周期，大家不是为了仅仅完成某个功能，而是提供一个持续改进、提升的服务。
- 数据去中心化：允许不同的存储方式或者存储位置，但要考虑分布式一致性的成本
- 强终端弱管道：即弱化类似SOAP的通信机制（通信管道设计很重，所有服务强制依赖，多了很多不必要的管道功能）， 如果有调用需要，提供服务终端的endpoint去调用而不是强制管道使用。
- 容错性设计：认为各服务是可以出错的，并不会直接影响所有服务的运行
- 演进式设计：不仅可以容错，也可以允许某个服务突然被淘汰
- 基础设置自动化：通过CI/CD等自动化构建、发布、运维，减少人工维护成本
微服务相比SOA的优势#
微服务不是SOA的变体或者衍生品，微服务中的每一部分可以自由的选择其中的各种可选方案。
例如远程调用有RMI、Dubbo、Rest，服务发现有ZK、Etcd等。
也正是因为选择很多，对于架构师而言是一个很沉重的挑战
5 后微服务时代（云原生时代）#
用硬件方案替代软件方案#
对于注册、跟踪治理、均衡等问题，能否脱离应用代码实现， 直接在硬件层面来实现？
很早以前行不通，因为硬件基础设置跟不上软件应用的灵活性。
直到docker和k8s的出现。
微服务时代离不开以docker为代表的早期容器化技术
微服务框架springCloud所支持的软件级别微服务治理功能，都能够在k8s中找到硬件层面的替代：
| 微服务功能 | K8s | SpringCloud |
|---|---|---|
| 弹性伸缩 | Autoscaling | N/A |
| 服务发现 | KubeDNS | SpringCloud Eureka |
| 配置中心 | ConfigMap | SpringCloud Config |
| 服务网关 | Ingress Controller | SpringCloud zuul |
| 负载均衡 | Load Balancer | SpringCloud ribbon |
| 服务安全 | RBAC API | SpringCloud security |
| 跟踪监控 | Dashboard | SpringCloud turbine |
| 降级熔断 | N/A | SpringCloud Hystrix |
通过k8s和相关的虚拟化技术， 与业务无关的技术性问题可以从软件层面剥离，直接在硬件设置层面进行解决！
第二次进化#
当涉及调用链路的切换或者变更， 单纯依靠DNS的硬件层面来做切换还是比较困难的，不如软件方案灵活。
于是引入了“服务网格”的边车代理模式
类似于脱离应用代码，在容器中部署一个通信代理服务器，对于请求的熔断、变更、流量控制都可通过这个代理服务器来管控。这样微服务应用代码中无需再考虑任何和上面这些通信过程相关的逻辑了，全部通过第三方的代理服务器实现！
6无服务（ServerLess）时代#
无服务的定义#
- 后端即服务： 数据库、存储、日志等业务无关的后端等都存储在云上
- 函数即服务：供使用者调用的函数/接口都是运行在云端，调用者不需要考虑容量规划和算力问题
无服务的愿景#
- 开发者只需要纯粹地关注业务
- 不需要考虑技术组件，后端组件现成的，直接使用，不用考虑如何采购和选型
- 不用操心运维，运维能力交给云计算厂商。
无服务的缺点#
对于信息管理系统、网络游戏或者对后端接口响应速度较高的应用而言， 无服务并不是最佳选择， 因为无服务的函数肯定不会一直处理高活跃度状态，存在冷启动的情况，对于其响应性能会有影响
总结和思考#
在很多年前的架构或者介绍微服务的书中，基本都是从单体->SOA->微服务。但是现在，随着云原生和 serverless 等新概念的出现，微服务架构的发展已经越来越多元化。对于需要频繁接触云业务的开发者而言，这些新概念显得更加重要。在学习这个章节时，需要关注这些架构演进的原因和理由，比如SOA相比单体的优点和缺点，后微服务又是如何从理念上逐步领先了传统的微服务等。
而《凤凰架构》一书的后半章节内容，更多是聚焦容器、k8s等云原生的重要内容。
像基于容器、k8s的设计，云原生技术将原先软件能力中复杂的内容转移到了硬件层面进行替代，开发者能够用更集中的精力关心业务实现而非服务治理等繁杂的内容。
像华为云CCE服务对于部署云业务的服务而言就是云原生时代的重要一环，CCE服务可以面向云原生2.0打造CCE Turbo容器集群，计算、网络、调度全面加速，学习 CCE 服务可以帮助开发者更深入地了解 Kubernetes 和容器技术，从而提高自己的微服务开发和容器化应用部署能力。
而无服务一般也是基于容器实现，对使用者而言基本不感知底层硬件资源，只需要调用即可，大大减少了创建和维护的学习和精力成本，即开即用的理念。 像华为云数据湖探索DLI、 华为云湖仓构建LakeFormation等都是基于serverless实现的云服务，云用户基于这些serverless服务并结合华为云MRS等大数据底座之后，可以快速运行自己的大数据作业或者数据统一管理等能力，构建数智融合的相关能力。
总而言之，相比于传统的微服务架构，云原生和 serverless 技术更加灵活、高效，能够更好地满足用户的需求。