20年前，超越时代的应用架构设计之美

记得自己在2003年参与的项目，使用了JSP、Servlet、JavaBeans和JDBC所组合的最原始的Web应用框架。

对于一位牛逼的资深级程序员来讲，这种原始的应用框架能写出最整齐、简洁与极致高性能的代码。

但是软件工程需要更多人参与进来，原始的框架容易变得混乱，原因就在于太多纯粹性的技术问题束缚了开发团队，那么参与者越多，代码堆积的熵增就越显著，项目也逐渐陷入泥潭。

因此，各种Web架构总是被顶尖的工程师们不断更新迭代、推陈出新，引导工程师们去关注业务本身，而非琐碎的技术问题。

从这我们就能一窥应用架构设计不断演进的本质——要让开发者挣脱技术复杂性所带来的枷锁，寻求更为灵活的规则与约定的设计，实现有序与自由的最大兼顾。

开发者能灵活地应对需求，专注于业务的构建，摆脱复杂与混乱，这也是我们寻求自由之美的意义。

在那个年代，工程师们对科技生产力提升的尝试远远超出了我们的想象，比较典型的例子就是EJB(Enterprise Java Beans)技术。

什么是EJB呢？封装业务逻辑的组件，解放了开发者的生产力，使开发人员无须再操心数据库访问、分布式事务处理、安全性、多线程并发问题等琐碎任务的编程技术。

这是在1998年提出了的架构设计，这种技术目标就算放到现在也一点都不过时。

EJB作为超越时代的分布式应用架构设计，在20年前就被广泛应用与尝试，尽管它的尝试最终失败了，也催生出了更多伟大且流行的开源技术框架，例如：Spring框架生态。

但是我们重新翻看那一段历史，只是为了去欣赏EJB的分布式架构所带来的自由之美，钦佩天才般的科学家和IT工程师们的创造力以及对于未知领域的勇敢尝试。

如下图1 - 1 EJB 3.x应用架构示例所示：

图1 - 1 EJB 3.x应用架构示例

来自于我在2010年参与的一个电商项目，使用了分布式应用架构的部分应用案例。

主要应用EJB 3.0架构，部署在云端跨区域的两台Amazon EC2虚拟节点，分别管理着各自的Amazon RDS MySQL数据库。

这种分布式架构中，每个EJB业务组件都是独立部署在一个上下文容器中运行，通过网络互相通讯与协作，组件可在本地与远程复用，甚至实现了分布式事务。

对比原始框架，业务模块被分布式组件化后，就遏制了工程无节制的代码堆积，开发者不用去操心复杂的事务问题、实例管理问题和并发安全问题，就能极大提升团队协作分工的组织效率。

这就是EJB利用分布式的组件化技术，在寻求自由灵活的开发方式上，为开发者带来了开山祖师般的全新体验。

上图中的EJB应用架构示例难道不够优雅吗？

为什么最终还是无法成为行业主流而逐渐没落呢？这其实是我们思考的关键。

EJB自身在部署方面的臃肿，分布式架构的复杂性在当时是非常重要的原因，但我认为更关键的原因在于使用中间件服务造成的依赖性远大于后来居上的Spring框架生态。

开发者对这些中间件服务的依赖严重，实际上就加重了对自身的限制。

对于开发者来讲，希望整个开发过程更为灵活与自由，这是一种近乎本能性的向往；同时希望团队协作过程有序且清晰，这是社会分工的内驱力。

自由与限制需要一种权衡，优秀的平台框架能通过精妙绝伦的技术设计，在兼顾两者的情况下，侧重开发自由，降低平台限制，实现具有美感的开发方式，这对于我们都是至关重要的事情。

从这里我们就能看到一种流行的趋势：Serverless（无服务器技术），本质上就是在不断解放开发者的生产力。

例如：亚马逊云科技于2014年率先推出的事件驱动无服务器(event-driven serverless)计算服务 Amazon Lambda.

开发者不必再操心服务器与后端基础架构的琐碎技术，而是借助触发器、不同编程语言的功能函数，专注于业务代码的构建。

在文件处理、实时流、Web应用程序、物联网IoT、移动应用等各个关键领域，结合Amazon Lambda，可以构建出伸缩性很强的基于Serverless的分布式应用系统。

当今微服务、分布式和容器技术的演进融合之美

以Amazon为首，云计算平台在IT基础架构中扮演着越来越重要的角色，工程师们主要谈论的Web应用架构也逐步提升为云服务架构，这时候我们已经进入到了云时代。

传统部署架构逐渐被云平台所替代，在云平台之上则是更为轻量化的微服务架构与容器化技术，承载了主流的云应用项目。

然而随着互联网用户规模化，高并发、大规模数据所引发的问题往往会更致命，高可用、并行提升性能的需求愈发强烈。

另外，项目中软件系统的开发规模也在不断膨胀，单体架构的工程化组织管理必然会随着长期维护而走向臃肿与混乱。

面对这些难题，微服务架构为开发者打开了一个更为适度、自由、灵活的新局面，并且在微服务项目具体实施的过程中，又与分布式架构紧密结合在了一起。

微服务架构的自由之美

前几年，我曾负责互联网医疗微服务平台的架构设计。

这个项目的特点在于将医疗信息化的肌体装进互联网的外壳中，因此，医疗业务的复杂性与互联网的技术平台性需要同时兼容。

如下图1 - 2 互联网医疗微服务与分布式架构示例所示：

图1 - 2 互联网医疗微服务与分布式架构示例

网关与微服务之间、微服务与微服务之间、微服务与各个Amazon RDS数据分库之间就形成了一种分布式的拓扑结构，另外承载高并发的关键微服务也可以由多实例副本形成均衡负载。

微服务模型单元要比过去EJB模型单元更粗粒度，是以服务为基准而非组件，这样就给予了架构师更为灵活的自由度。

按需划分适合大小的服务粒度并进行适当的分布，也就不会对开发者硬性规定底层需要依赖什么样的服务，这就保证了输出的软件具有平台无关性。

微服务架构之所以能形成如此强大的一股潮流，其原因就在于面对互联网规模化的时代，可以让应用架构呈现出自由、灵活与开放的一面，同时又能对软件易于混乱的特征分而治之。

这与我们前面所说的兼顾有序与自由的应用架构设计的本质形成了很好的印证，它为开发者应对客户需求的软件应用设计，提供了一种自由的张力，这也是工程师们不断追求自由之美的关键价值。

容器技术的灵活之美

软件应用架构发展到了微服务这个阶段看起来应该很不错，可是现在又面临一个问题，微服务架构必然需要用掉更多的计算资源，而且更适合于分布式架构环境，在采用更多机器组成的分布式网络节点的情况下，如何才能优化计算资源的使用？

这时候容器化技术的价值与作用就体现出来了,例如：Docker引擎管理的容器作为操作系统上的一个进程，保证了容器之间互不影响，并且可以针对容器的CPU、内存等计算资源进行预先分配，容器镜像对程序的封装让发布过程简单到一条命令就能正常运行。

这样就极大简化了服务在云服务器上的部署难度，提升了更高的效率，甚至我们可以同时部署多个版本的服务，形成生产与测试环境的并存。

当我们感受到容器技术带来的自由与灵活，可是如何让开发者忘却容器管理引擎、分布式架构部署的复杂性问题呢？

其实在上面的微服务案例中已经给出了答案，整个微服务实例全部由早期Amazon EC2 + Docker容器引擎的部署模式，迁移到了Amazon ECS平台之上。

通过Amazon Fargate实现了Serverless部署，不用考虑容器的分布式部署问题；在项目前期完全不需要考量计算资源的规划问题，因为在业务不断增长的情况下，Amazon ECS可以实现计算资源的动态伸缩，实在是太灵活了。

接下来我们就展开聊聊在云服务架构环境下，Amazon ECS与Serverless技术为开发者摆脱底层环境束缚，到底带来了哪些服务支撑。

Amazon云容器与Serverless技术的支撑之美

Amazon云容器的整体之美

当我们拥有了微服务、分布式架构与容器技术，那么云厂商又为此提供了怎样的支撑呢？

我还是比较看好Amazon领导的这种云服务理念，因为Amazon云技术正在朝着Serverless的方向进行发展，尤其是充分利用了容器技术的出现，加快了这一步伐。

前述案例中的Amazon ECS全称是（Amazon Elastic Container Service），它是针对容器技术高度弹性的管理服务。

Amazon ECS希望用户直接面对容器，而不是面对操作系统，也就是说Amazon云平台提供给用户购买的计算单元粒度更细致了。

那么这又带来了什么好处呢？

其实是两方面：

优势一：我们没必要就为了部署一个服务，就得先占用一台虚拟机OS，现在Amazon ECS给了一个新方案，部署维护一个Docker容器就够了，它会自己维护计算资源的基础设施。

由于资源占用少了，自然我们充值就少了；

优势二：现在的云服务大趋势是分布式，这样我们的应用可以形成集群，以便增强系统高可靠性以及对服务性能的弹性伸缩管理。

Amazon ECS默认提供的Serverless模式就让开发者不再顾虑运行服务的集群分布问题。我们只考虑要上多少Docker容器，至于放置在什么地方，哪个机房，哪台服务器，那都是Amazon ECS的Serverless技术考虑的事情。

那么我们就用一个整体上较低的综合成本，实现了一个真正强大的面向服务的集群环境。

而Amazon的ECS、EFS 、EC2、ECR是什么关系呢？

如下图1 - 3 Amazon ECS、EC2架构体系示意图所示：

图1 - 3 Amazon ECS、EC2架构体系示意图

Amazon EC2是Amazon提供的虚拟机，它与Amazon ECS共享基础设施，形成相互协作。

通过Amazon EFS就可以将Amazon ECS任务的容器目录挂载到EFS上，那么Amazon EC2实例就可以通过网络文件系统(NFS)挂载到本地目录的方式，去访问EFS中ECS容器的内部文件。

Amazon ECR是Amazon提供的Registry仓库，为Amazon ECS提供容器镜像服务，不仅使用方便，私密性也很好，而且比建立私有Registry仓库的维护成本要低得多。

从上述架构介绍中，我们就可以看到Amazon云平台是系统化地提供了整套云容器化解决方案。

Amazon ECS的Serverless架构之美

对于Amazon ECS的管理核心就是Amazon Fargate（Amazon的Serverless技术），它可以将Amazon ECS任务（本质上就是容器实例）放置在集群的不同位置，形成高可靠的分布式系统，至于服务到底放置在分布式网络中的哪个计算节点之上，是不需要开发者操心的。

如下图1 - 4 Amazon ECS和Fargate技术结构体系示意图所示：

图1 - 4 Amazon ECS和Fargate技术结构体系示意图

我们只需要详细地对容器任务和服务进行配置描述，然后将配置提交给Amazon ECS。

Amazon Fargate会创建任务实例，每个任务都是独立运行的一个服务，每个服务并不独占一台计算节点资源，但又能通过资源配额的自动扩展来应对更大的外部请求吞吐量。

另外针对Amazon ECS的应用服务是基于界面配置，并不利于自动化发布运维服务，Amazon又进一步提供了命令模式的Amazon Copilot，进一步实现完全自动化的CI/CD管道。

如下图1 - 5 Copilot显示服务状态示例所示：

图1 - 5 Copilot显示服务状态示例

我们可以通过终端命令："copilot svc status"，就能拿到"ecsdemo-frontend"这个容器服务的状态信息，通过捕获的状态信息。

我们可以进行程序级的二次分析，应用在我们的日志、运维监控等功能当中。

因此Amazon ECS最大的优势还是在于提供了特别强大的图形界面配置功能和命令运维的工具集合功能，不仅包括了Amazon Copilot，还有Amazon ECS CLI、Amazon CDK等。

这些功能可以通过非图形界面的终端命令方式、编程的方式(TypeScrpit、JavaScrpit、Python、Java、C#) 更全面且细粒度的创建与维护Amazon ECS基础设施，控制和优化Amazon ECS集群与任务。

展望云服务架构的未来

通过上述各章节的描述，我们可以看到应用服务架构的进步，二十年前还需要重度依赖中间件及底层服务，如今逐渐演进到了Serverless的时代，这是无数工程师、开源社区以及像亚马逊云科技（Amazon Web Services）这样的商业公司所共同努力的成果。

那么我们畅想一下云服务架构的未来，我认为基于云平台的Serverless架构应该会成为主流模式，Serverless会让开发者更加关注业务本身，而非基础设施与琐碎的基础技术。

但是对于开发者来讲，Serverless的优势在于分布式计算资源的自动调度，但是分布式架构的复杂特性又会让很多开发者难以理解。

因此，云服务厂商必然会在这个方面的基础设施层进行发力，例如Amazon EKS就是在云环境下创建和运行K8s集群提供了整套解决方案，目标就是让开发者不用关注复杂的分布式问题。

我相信这种去分布式复杂化的基础设施必将对应用软件架构起到越来越重要的作用，也会变得越来越流行。

开发者可以在这样的平台之上，既能获得更大的自由与灵活度，专注于自己的业务功能改善，又能充分利用分布式技术优势，让更多的开发者在Serverless时代充分感受到自由之美。

报名开启 | 自由构建 探索无限

亚马逊云科技2022 Dev Day 重磅来袭，不容错过！

多位大咖现身说法

如何用充满“技术美感”的方式

帮助开发者

实现更简单、自由、高效的开发

此外，还有大量专家观点碰撞

技术展、创新赛、动手实操等环节

精彩不断，干货满满

携手大家一起“自由构建，探索无限”

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。