漫谈架构演变之路：为何要搞微服务架构？今天就为大家讲透！_现在还有哪些企业是单体架构

有不少朋友或同事都问过我这个问题：为什么我们要搞微服务架构，一个项目把代码从头撸到尾不是很方便吗，开发更快速，部署也容易。而且一提起微服务，涉及的技术就一大堆，好像几辈子也学不完。

怎么解答这个问题呢？我想还是通过架构的发展变迁史来说起，为什么会出现现在的各种架构。只有从整体上了解了架构的脉络，我们才好更加全方位的评估一个架构。为此，我们有理由来梳理一下架构发展的来龙去脉，究竟为何会出现微服务，主要解决什么问题。微服务架构是最先进的架构吗？

本文我们来探索一下架构的变迁。以及从Java工程师的角度来看技术的发展，了解我们在讨论微服务的时候，都会涉及哪些技术。微服务的下一步将如何发展。阅读完本文，你将了解到：

1. 软件架构的发展史
2. SOA架构与MSA架构的区别
3. 微服务架构核心关注的问题是什么
4. 如何做微服务架构的技术选型
5. 目前架构正在朝着什么方向发展
6. 架构升级与业务发展的关系，一定要用最前卫的架构技术吗？什么样的架构才是好的架构
7. 微服务的难点是什么，这里主要留给大家思考，会在后续文章中进一步讲解

---

首先我们还是回顾一下架构的整体发展史。

架构发展史

架构也是随着其缺陷不断演变而来的，下面是粗略的架构演变史：

70~80s：集中式(大型机)

上世纪70年代和80年代，大型机是计算机的工作方式。

问题所在：最初的大型计算机使用打孔卡，并且大多数计算都在批处理过程中进行。没有在线处理，并且延迟为100％，因为没有实时处理。

架构演变：随着在线处理和用户界面终端的推出，大型机范式发生了一些变化。

90s：CS架构(分布式)

客户端/服务器体系结构将大多数逻辑放在服务器端，并将某些处理放在客户端上。

问题所在：在该体系结构的最初几年中，开发社区仍在使用与大型机开发相同的过程，采用单层原则来为客户端/服务器编写软件，从而产生了诸如意大利面条代码和Blob之类的反模式。

架构演变：引入了一项称为面向对象程序设计（OOP）的重大改进；

客户/服务器模型基于三层体系结构，包括展示层，业务逻辑层和数据层。但是大多数应用程序是使用两层模型编写的，胖客户端将所有展示、业务和数据访问逻辑封装在一起，直接访问数据库。尽管业界已经开始讨论将展示与业务与数据访问分开的必要性，但是这种做法直到基于Internet的应用程序问世才真正变得至关重要。

2000：去中心化(Internet)

在90年代中期，互联网革命发生了，Web浏览器成为客户端软件，而Web和应用程序服务器托管所有处理和逻辑。

问题所在：开发人员仍在将软件设计为紧密耦合的设计，从而导致混乱和其他反模式。

架构演变：作为解决办法，业界提出了三层体系结构和实践，例如领域驱动设计（DDD），企业集成模式（EIP），SOA和松耦合技术。

2006：云托管

21世纪前10年见证了云计算作为服务托管形式的重大改变。应用程序需要的一些能力，云计算平台托管了基础功能：分布式计算、网络、存储以及计算等，与传统的基础架构相比，云托管的方式能更好的控制成本。

问题所在：它诱使将尚未设计用于弹性分布式架构的遗留应用程序直接迁移和迁移到云中，从而产生了单体地狱这种反模式。

迁移到云还给行业带来了管理第三方库和技术上的应用程序依赖项的挑战。没有足够的标准来选择第三方工具，我们开始看到一些依赖地狱。另外服务扩容也是一个问题。

架构演变：了应对这些挑战，业界提出了新的架构模式，例如微服务和12要素应用程序[1]，弹性服务。

2014：微服务

诸如DDD和EIP之类的软件设计自2003年左右就已经开始实践起来了，此时一些团队将应用程序开发为模块化服务，但是传统的基础结构（如Java应用程序的重量级J2EE应用程序服务器和.NET应用程序的IIS）对模块化部署并没有帮助。

随着云托管的出现，尤其是诸如Heroku和Cloud Foundry之类的PaaS产品的出现，开发人员社区拥有了真正的模块化部署和可扩展业务应用所需的一切。这引起了微服务的发展。微服务为打造细粒度、可重用的功能和非功能服务提供了可能性。

问题所在：原本的单体系统、未被设计为微服务的传统应用程序开始被蚕食，试图迫使它们进入微服务体系结构，由于拆解的不当，从而导致了被称为微单体的反模式。单体和微服务是两种不同的模式，后者并不总是可以替代前者。如果我们不小心的话，最终可能会创建紧密耦合，混杂的微服务。微服务剧增的另一个不希望出现的副作用是所谓的“死亡星球”的反模式。

架构演变：诸如服务网格，边车，服务编排和容器之类的新兴架构模式可以有效地防御基于云的世界中的渎职行为。随着云平台的出现，特别是像Kubernetes这样的容器编排技术，服务网格已经引起了人们的关注。服务网格是应用程序服务之间的桥梁，可添加其他功能，例如流量控制，服务发现，负载平衡，弹性，可观察性，安全性等。

几种架构反模式[2]说明

• 单体地狱[3]：
  • 好处：早期开发简单、易于对程序做重大更改、直接测试、直接部署、易于扩展；
  • 缺点：随着业务增长，暴露问题：复杂度高、开发效率低下、从提交到部署耗时长、伸缩性差、技术栈过时难以升级、缺乏故障隔离导致一个小功能可能会影响整个系统；
• 微单体[4]：
  • 一种非弹性和不可扩展的微服务系统，即所谓的微单体；单体和微服务是两种不同的模式，后者并不总是可以替代前者。如果我们不小心的话，最终可能会创建紧密耦合，混杂的微服务(微单体)。我们应该根据应用程序功能的业务和可伸缩性要求做抉择；
• 积木塔：单体应用程序类似于积木塔：您永远不知道发生故障时哪块砖可能会出问题。由于该应用程序的所有模块都在同一进程中运行，因此，如果某个模块受到错误的影响，则会降低整个过程，从而影响整个应用程序。 在完成故障排除之前，您可能会失去数百甚至数千个商机；
• 科学怪人[5]：科学怪人是一部著名的美国电影，讲述了一个天才科学家创造了一个怪物最终被其毁灭的故事。Istio 团队为以它来自嘲。Istio 本想扮演上帝一般的角色&