微服务架构的正常运转,离不开一组精心构建、且能够高效协同运作的独立组件。正是模块化组件间的相互依存,构建起规模更大的应用程序本体。
但在实际开发中,在微服务分解成最基础的单元时,确保微服务以最基本的方式运作绝非易事。如果做不到这一点,应用程序的整体效用根本无法实现。不要因为设计错误而拒绝微服务架构,牢记以下五项黄金设计原则,你的微服务架构将拥有强大的组件支持。
第一,专注处理一个问题。迈进微服务的第一步,就是为服务设定唯一的问题。例如,我们假定一家汽车贸易组织希望构建一款应用程序,借此将潜在的买家与卖家联系起来。以此为基础,将有专门的微服务组件处理汽车交易中的买、卖或者转售等操作,任何服务除此之外再无其他用途。
付款环节正是设计中的另一个重点组件。虽然这两项微服务可以相互结合并使用,但这些服务并不会融合起来。每个元素负责处理不同任务,而且始终能够独立起效。
第二,具备离散属性。微服务在执行工作时所需要的全部逻辑及数据都存在于自身内部,而且与其他微服务组件完全隔离。
虽然微服务往往也需要自身配置才能让各内部组件正常运行,但是这种配置不会对其他微服务的配置产生影响。只有牢牢把持这项设计原则,开发人员才能根据实际负载需求随时完成各项服务的规模伸缩。
第三,带有自身数据。微服务不仅应带有自身数据,这些数据还应独立于其他微服务组件之外。在某些情况下,微服务甚至可能拥有自己的数据库。在其他场景中,微服务可能与其他服务共享同一套数据库,但仍在该数据库中拥有自己所对应的唯一数据库表。
通常来讲,开发人员会使用共享数据库以降低成本,但这明显违反了微服务架构的设计原则。
开发人员往往需要在设计中同时考虑到数据的独立性与冗余性。每项微服务自带数据的设计方式可能在应用层级上引发数据重复,但开发者们开始逐渐接受微服务设计模式必然引发数据冗余这一基本事实。
要了解不同微服务之间的数据重复问题,最直观的示例莫过于存储在不同在电子商务平台手中的客户数据。具体来说,同一用户很可能分别注册了Amazon与沃尔玛,因此两个网站都掌握着该用户的一套数据。但由于两个网站保持离散且隔离性极佳,因此除非拥有明确的数据访问授权,否则二者都意识到该用户的数据也存在于另一网站之上。
第四,具备可传递性。所谓微服务的可传递性,代表着我们可以将其“打包”至部署单元,例如容器镜像或者无服务器函数当中,并随时通过CI/CD流程部署到给定的目标中。
举例来说,开发人员可以轻松将可传递微服务部署至Google Cloud这类云服务商。万一需要将其部署至其他云平台,开发者则可随时将同一项微服务传递至AWS。
第五,具备临时性。微服务的临时性,意味着我们可以随时将其销毁,而后立即将服务恢复至最近的已知状态。
容器的临时性质不仅决定了当前容器发生离线后、应用程序状态的管理方式,同时也将影响到活动线程的管理思路甚至是活动线程的具体设计,确保代码不存在基于线程的依赖项。
这五大黄金原则,应当成为一切微服务架构的核心设计要求。请认真考量每项原则,据此建立起适合当前应用程序的良好架构。
好文章,需要你的鼓励
OpenAI于周二发布AI浏览器ChatGPT Atlas,目标是让ChatGPT成为搜索和问答的首选界面而非谷歌。该浏览器目前仅支持Mac,但正在开发Windows、iOS和Android版本。Atlas将ChatGPT设为默认搜索选项,并具备记忆功能,可结合浏览历史提供个性化答案。与其他AI浏览器不同,Atlas更专注于强化ChatGPT生态系统,为OpenAI提供更多用户数据和分发控制权,而非改善传统浏览体验。
浙江大学团队提出动态专家搜索方法,让AI能根据不同问题灵活调整内部专家配置。该方法在数学、编程等任务上显著提升推理准确率,且不增加计算成本。研究发现不同类型问题偏爱不同专家配置,为AI推理优化开辟新路径。
通用汽车宣布计划于2028年推出自动驾驶系统,允许驾驶员双眼离开道路、双手离开方向盘,首先应用于凯迪拉克Escalade IQ。该系统基于现有Super Cruise技术,采用激光雷达、雷达和摄像头感知技术,初期在高速公路使用。通用整合了已关闭的Cruise子公司的技术栈,包括基于500万英里无人驾驶数据训练的AI模型。目前美国仅奔驰拥有商用L3级自动驾驶系统。
清华大学研究团队提出SIRI方法,通过"压缩-扩张"交替训练策略,成功解决了大型推理模型"话多且准确率低"的问题。实验显示,该方法在数学竞赛题上将模型准确率提升43.2%的同时,输出长度减少46.9%,真正实现了效率与性能的双重优化,为AI模型训练提供了新思路。