从 到

1. 从函数入手

我是1993年开始学习计算机的，需要学习三种开发语言：汇编、C、。

所以我在学习的时候，对于面向对象的代码架构设计和代码编程实现都不太了解。因此，要从字面上区分函数之间的关系，我们主要依靠给函数命名，将它们放在同一个代码文件中，将它们放在同一个代码目录文件夹中，以区分它们之间的相关性。

在当时的函数时代，还没有异常保护、异常处理、异常日志等编写函数的基本原则。因此，除了命名之外，我们主要关注的是函数的输入数据参数和格式，以及输出数据的参数和格式。

2. 面向对象

我开始使用面向对象的软件，但是当我真正开始编写大量面向对象的代码时，我才开始使用它。那已经是1996年的事了。

由于类的存在，函数可以组合在一起。有些函数是私有函数，只能在本类内部调用，有些函数是公共函数，可以在外部调用。

但当时我对类的使用还很基础，经常会在源代码文件中定义一个类。而且，类不使用继承，这意味着我所有的类都是并行的，类之间的关系是通过公共函数调用。

3、面向接口

这种开发语言的美妙之处在于它的定义语句和它的详细实现是分离的。

业务功能变得更加复杂。以前关系不大的业务，现在联系越来越紧密，一些类之间的调用太多了。

我只想重写这段代码并合并这两个类。但一旦重写，需要移动的东西太多了。

使用继承或多重继承来做到这一点。太麻烦了。你必须在实现中写一个空函数（也就是说，没有代码，只有一个函数框架，以防编译器可以通过语法）。

后来，当我了解接口时，我使用接口来定义它们，而不是使用空函数。只需定义它们而不实现它们，编译器仍然可以通过。

4.面向组件

我彻底经历了面向组件的时期，并使用面向组件的技术编写了整整一代完整的ERP参考套件。从技术到COM/DCOM/COM+技术，我都学会并熟练运用。我也完整体验了单机版到C/S客户端服务器局域网版到C/S/S三层架构。

一开始，我是写应用程序的。 UI开发、业务逻辑开发和数据库开发都是用一种开发语言完成的。

后来写C/S应用时，使用了大型关系数据库，在数据库层写了很多存储过程和定时JOB任务。但当时业务逻辑代码和UI代码都运行在客户端，所以这两层之间的分离并不清晰。

然后写一个C/S/S三层架构。业务逻辑层独立，物理独立部署。这样客户端代码和业务逻辑层代码必须完全分离，不能不明晰地混在一起。那时，我开始广泛使用仔细的界面设计和对象设计。

因为有独立的业务逻辑层，所以对这些代码（接口/类）何时创建对象实例、何时释放、这些对象实例应该运行在哪个流程容器中都有要求。

这样，就创建了组件容器和组件。组件容器管理组件的整个生命周期（安全、创建、并发访问控制、睡眠、激活和唤醒、计数、销毁和内存释放），组件管理器管理组件注册、发现等。

所以《COM的本质理论》的作者Don Box说.NET是一个更好的COM。我突然明白了：是的，微软的意思是未来所有的应用程序都应该运行在组件容器中，无论它们是独立的应用程序。无论是C/S应用程序还是C/S/S应用程序，每个应用程序都必须运行在组件容器中，组件容器屏蔽并管理内存的创建和回收。

不要将内存的创建和释放直接暴露给开发人员，否则开发人员技术能力参差不齐。一些不好的程序员不能很好地管理内存，很容易让应用程序占满内存而导致操作系统崩溃。

5. 方向

哈哈哈，大家好像没听说过定向，但是大家好像都听说过服务定向。

随着Web和互联网的兴起，HTML（UI元素定义）+CSS（UI元素样式定义）+（UI元素操作）构成了前端技术。

人们把XML从前端分离出来，成为一个数据容器。您可以使用HTTP+80端口传输纯文本XML数据，也可以使用UDP、TCP/IP等各种传输协议。

当然，XML也可以被压缩，以便能够以更小的尺寸在互联网上传输（尤其是过去网速很慢的时候），还可以对其进行加密，以防止别人拦截和看到。这些构成了一个技术家族。

我们现在要将LAN版本的C/SS/三层技术架构升级为Web/S/S三层技术架构。我们应该做什么？

所以我们需要在组件之上再包装一层，以便可以调用客户端AJAX技术。

因此，当时的.NET组件技术、EJB技术、.NET组件容器、EJB组件容器中间件都原生内置了对该技术家族的支持，以至于从开发到运行到调用一切都直接是一种技术。这就是SOA：面向服务的架构。

微服务

1、事情走向极端就必须扭转局面

当时是多么理想：一个完整​​的J2EE系统，+EJB完美的组件模型+SOA组件容器/ESB组件管理器中间件，包括技术架构师。那时候的市场是多么巨大啊。

但程序员是实用主义者，他们可以做任何简单的事情。随着第二波互联网创业浪潮（2004年）的兴起，最好的起步方式就是大而快地起步，没有钱的话从开源开始是最好的方式。

于是，REST被替代了，XML被JSON替代了，EJB被普通JAVA替代了，开源被替代了。

尤其是2004年到2006年，SSH三驾马车（前端、中间层、数据层）真正一统天下。

尤其是2004年到2006年，它上升到了很高的高度，统一了自己的Open API，非常轻量。这是微服务的流行开端。但此时还不能称为微服务，可以称为简化服务（）。

2. 亚马逊规则

自2002年起，贝佐斯亲自为亚马逊分布式系统架构制定了六大原则：

1.所有团队程序模块必须通过接口公开其数据和功能。

2、团队之间的程序模块之间的信息通信只能通过这些接口进行。不允许其他形式：不能使用动态链接库、不能读取其他团队数据库、不能尝试共享内存、不能尝试别人模块的后门。唯一允许的通信方式是呼叫。

3. 所有网络无一例外都必须设计为对外部世界开放，无论是内部还是表面。也就是说，团队必须好好规划和设计，将来向全世界的程序员开放接口，不能有任何例外。

4. 不这样做的人将被解雇。

5、一个服务由一个小团队负责（两个披萨喂饱），从前端到数据、从需求分发到线上运维全权负责。

6、逆向工作方法：先定义未来，然后发布新闻稿供客户探索和互动，然后实施。

当我看到这六个原则时，我明白了为什么亚马逊能够成为公共云计算的领导者。我也了解到亚马逊在现在很流行的情况下仍然坚持使用AWS品牌（Web）。

我个人认为只有亚马逊功能齐全的小团队以及内外融合的原则打通之后，服务才会真正变得更小，成为微服务。

如果你是一个100人的团队，你是一个按专业职能划分的团队，你是一个每年发布两次的团队，你是一个区分内部调用和外部调用的团队，我相信你是做不到的。成为一支真正的团队。微服务。充其量只能说你是一个使用微服务技术但不实现微服务的团队。

这很容易理解。很多程序员一生都在使用面向对象的开发语言，但自己却从未定义过真正的类。

云时代

1.移动时代已经到来

20世纪90年代，我们使用C/S、C/S/S和DCOM/COM+。 2000年以后，我们使用.NET和EJB/，后来我们使用REST和JSON。这就是业务逻辑层技术的全部演进和变化史。

在客户端，上网速度越来越快、越来越便宜，屏幕越来越大，性能越来越高，内存越来越大，呈现给客户的功能越来越多，UI界面也越来越好。变得越来越复杂。

这个时候如果想考虑微服务其实是相当困难的。您无法抗拒诱惑，总是想为其添加更多功能。反正客户端性能高，屏幕大，能搞定，就没有坏处。

但2011年中国开始了移动时代。手机上网速度慢，资费高，性能慢，内存小，屏幕小，没有键盘和鼠标，只能用手指滑动屏幕。因此，微信是从语音消息而不是短信（打字真的很难）中诞生的。

屏幕小，没有键盘鼠标，输入输出困难，功能必须精简、简化。这就迫使业务逻辑层不能太复杂。

因此，即使没有亚马逊的六大火规则，微服务也已经在移动时代真正大规模流行起来。

现在小程序技术依托微信平台（统一客户、统一IM、统一支付）来简化开发、部署和发布。

由于每个人都拥有可以随时随地访问的智能设备，因此企业比以往任何时候都更容易与最终消费者建立联系、接触和互动。

因此，企业应用开始从以内部管控建设为重点转向以连接消费者、与消费者互动、消费者直接下单交易等业务为重点。

软件应用程序的主要用户已经从可以控制和解雇他们的员工转移到为企业付费的父母。

你不能得罪你的父母。这会影响你的销售业绩，所以你需要坚持下去并快速提高。

因此，为了更快、不跨专业职能部门协作，各个研发团队也进行了自我重组，从专业职能部门的组织形式转变为亚马逊式的全功能小团队，这进一步推动了微服务的落地。

所以，行动限制正在迫使人们努力工作，也迫使父母努力工作。正是在移动时代，大规模万金油程序员学会了实现微团队、微项目、微功能、微服务。

2、云时代来临

由于企业应用的重点已经从数量可观的企业员工用户转向大规模的外部消费用户，高性能并发和海量数据的技术需求随之而来。

然而，企业应用开发者始终面临着企业内部用户的规模。他们不是互联网公司。他们没有经验如何应对。

恰逢云时代来临。

它提供分布式对象系统、分布式数据库、分布式大数据技术平台、分布式消息队列中间件。

当然，它已经升级为分布式微服务中间件。哦耶，我终于跨过了这个技术门槛了。

别高兴得太早。由于它是分布式的，并且面对大量的最终消费者，因此部署工作变得复杂。

与以往制作企业内部管理应用不同，服务器最多只有十几台，可以手动升级，企业员工下班就可以开始工作。

如今，它们都是消费者应用程序。消费者有不同的行为和习惯，需要 24x7 运行。此外，这些都是事务性应用程序。你不敢断开它们。你不敢一次全部升级。您害怕因交易错误而损失金钱。你买不起，所以还是需要灰度发布。

这需要工具。

所以它真正流行起来是在互联网时代和云计算时代。这是因为：海量用户、在线24x7实时运行、交易类型、大规模服务器、快速迭代开发、在线发布，必须与开发、运维融为一体。过去对运维人员的技术要求不高，但现在运维人员也需要具备开发技术能力。

为了更快地打包、分发、部署、升级、维护，人们发明了K8S。可以打包成镜像文件，隔离微服务的版本环境，使微服务在开发期和运行期保持一致。这极大地简化了分发、安装部署、升级和运维变更。

云原生应用程序

1. 为什么微服务不是微？

很多人很困惑微服务到底是不是微服务。

虽然有全功能的微团队（2片披萨）、微UI（移动App和小程序技术）、微项目（每两周迭代发布），但微服务仍然不是微。

虽然有可以满足海量用户高并发的分布式微服务中间件，有分布式部署和运维（//k8s），但微服务仍然不是微服务。

有什么问题吗？

让我们仔细看看开发过程。

作为一家软件公司，软件代码是我们的核心资产。所以我们肯定有我们私有的Git源码库，部署在我们公司的IDC机房，并且有层层安全防护和代码备份机制。

当我们要开发的时候，我们需要在本地安装和部署各种框架，以便进行本地开发和本地调试。但现在，为了应对高并发的分布式中间件、海量大数据存储和计算、人工智能训练、物联网接入，我们需要安装40多个依赖的技术框架。

正常部署和调整这堆框架我们就累坏了，而且这些框架之间一旦出现参数变化或者版本不兼容，就会死人。

好了，我们终于把这堆框架调整到正常了。当我们开发出具体的业务应用之后，我们就开始使用工具和工具进行打包、分发、部署。依赖框架这么多，你的微服务能微吗？

2. 云原生应用

正确的打开方式是什么？让我们想象一下。

第一步：将你的代码放在云代码平台上，而不是你公司私有部署的Git平台上。这就是微软花重金收购Git的原因。

这是第一步。为什么要这样做，接下来你就会明白。不管怎样，当你开发基于云计算、大数据、人工智能和物联网的特定业务应用时，你会严重依赖开源平台。您的特定业务应用的技术门槛很高。而且，微软接手Git后，企业代码的安全防护和备份远高于自己的管理员和运维技术。

第二步：使用云开发平台。这个开发平台可以基于网页浏览器，也可以基于本地VS Code IDE，但云开发平台的核心本质是：你不需要在本地安装那么多依赖框架。你在IDE中编写应用程序，你在云端的Git平台上打开一个源代码文件，打入一个包，然后直接在IDE中调用API，这个云开发平台就会自动完成API。你可以保存代码，可以编译代码，可以调试代码，还可以运行代码，就像在本地一样，但实际上应用程序运行在云端。它还在云端打包、安装和部署。

这才是真正的云开发平台，比如AWS。如今，已有不少李鬼带出了雅琪MIS二十多年前的同样玩法，快速可视化设计输入表单、图形化设置审批工作流程、快速可视化设计报表图表。这东西在世界上并不是独立的。市场是存在的，但它并不在我们今天所说的云原生应用开发路径上，或者说根本不适合开发者。

第三步：使用云服务开放API。云计算厂商将所有云服务开放给Open API（你能想到的六大规则）。您可以在该云开发平台上直接调用云计算厂商Open API平台中的所有API。这些云服务将负责自己的安装、部署、升级、监控、备份、迁移等。

3.终极：

最终的办法是：。当时IaaS、技术PaaS、应用PaaS、具体业务应用SaaS都非常丰富。大家都开放了Open API，还有企业微信、钉钉等统一门户平台，还有小程序UI前端技术。你打开了Web IDE，New A函数直接调用Open API，你的应用程序函数就串联起来了。

您无需担心打包、安装部署等细节。当你想运行它时，在云端后台，会自动为你启用并打包一套完整的工具集。它将根据您自己的云计算资源为您安装和部署。您不必担心它部署到哪台服务器。

随着您的应用程序性能的提高，它将自动迁移并扩展到更高性能的计算环境。这一切都与你无关。您每月只需一次性支付一笔费用。

否则，开发人员的效率无法提高；否则，软件公司只会使用云厂商的云硬件资源，其他软件中间件将开源并自行部署，而不使用云中间件。这样一来，云计算厂商想要赚钱就不容易了。大钱，毕竟硬件是刚性成本，只有软件才是高利润的，尤其是部署在云上的分布式中间件服务，规模大，利润高。