为什么选择事件驱动的微服务架构？
采用事件驱动的微服务是一项战略举措，它改变了企业和开发人员进行软件设计和管理的方式。正如这里所指出的，开发人员在时间、资源和高质量代码方面的好处是巨大的。…
如何开始使用事件驱动的微服务
许多组织在其发展过程中达到了这样一个阶段，即曾经为他们提供良好服务的单一应用程序开始阻碍他们的发展。也许业务需要现有架构无法支持的新功能，或者需要更灵活的方法来存储和访问应用程序的数据。团队成长、相互冲突的性能需求和新的竞争性技术也会对单一的代码库构成挑战。采用事件驱动的微服务架构可以帮助企业应对这些挑战。…
是微服务架构不香还是云不香
本文转载自 酷 壳 – CoolShell，作者：陈皓
原文地址：https://coolshell.cn/articles/22422.html
这两天技术圈里热议的一件事就是Amazon的流媒体平台Prime Video在2023年3月22日发布了一篇技术博客《规模化Prime Video的音视频监控服务，成本降低90%》，副标题：“从分布式微服务架构到单体应用程序的转变有助于实现更高的规模、弹性和降低成本”，有人把这篇文章在五一期间转到了reddit 和 hacker news 上，在Reddit上热议。这种话题与业内推崇的微服务架构形成了鲜明的对比。从“微服务架构”转“单体架构”，还是Amazon干的，这个话题足够劲爆。然后DHH在刚喷完Typescript后继续发文《即便是亚马逊也无法理解Servless或微服务》，继续抨击微服务架构，于是，瞬间引爆技术圈，登上技术圈热搜。…
单体应用与微服务
什么是Monolith，即单片架构？
单个应用程序，我们称之为Monolith，是通过单个部署单元提供的应用程序。示例可以是作为单个WAR提供的应用程序，也可以是具有单个入口点的Node应用程序。
例：
让我们举个例子：一个经典的在线商店。我们的业务范围包括订单，项目，客户，运输和付款。提供的与服务交互的方式有：REST api和Web前端。
构建Monolith，所有这些东西都将在同一个工件中进行管理。我没有编写“相同的进程”，因为对于我们的工件的多个实例将运行以处理更高负载的情况，这不是真的。
互联网架构实践心得：屡试不爽的架构三马车
这里所说的三架马车是指微服务、消息队列和定时任务。如下图所示，这里是一个三驾马车共同驱动的一个立体的互联网项目的架构。不管项目是大是小，这个架构模板的形态一旦定型了之后就不太会变，区别只是我们有更多的服务有更复杂的调用，更复杂的消息流转，更多的Job，整个架构整体是可扩展的，而且不会变形，这个架构可以在很长的一段时间内无需有大的调整。…
微服务架构入门
微服务架构入门
1. 微服务简介
微服务是一种架构风格，一个大型的复杂软件由一个或多个微服务组成。系统中每个微服务都可以被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成任务。在所有情况下，每个任务代表这一个小的业务能力。
微服务的核心思想是：一个完整的应用由多个小的、相互独立的微服务组成，这些微服务运行在自己的进程中，开发和发布都没有依赖。不同微服务通过一些轻量级交互机制来通信，例如RPC、HTTP等，服务可独立拓展伸缩，每个服务定义了明确的边界，不同的服务甚至可以采用不同的编程语言来实现，由独立团队维护。简单的来说，一个系统的不同模块转变成不同的服务！而且服务可以使用不同的技术加以实现！…
集群、分布式、微服务的区别
前言
开门见山，见标题。
概念
集群是个物理形态，分布式是个工作方式，微服务是一种架构风格。
集群
集群模式是不同服务器部署同一套服务对外访问，实现服务的负载均衡。…
软件架构入门
软件架构（software architecture）就是软件的基本结构。
合适的架构是软件成功的最重要因素之一。大型软件公司通常有专门的架构师职位（architect），只有资深程序员才可以担任。
O'Reilly 出版过一本免费的小册子《Software Architecture Patterns》（PDF）， 介绍了五种最常见的软件架构，是非常好的入门读物。我读后受益匪浅，下面就是我的笔记。…
微服务（Microservice）那点事
WHAT - 什么是微服务
微服务简介
这次参加JavaOne2015最大的困难就是听Microservice相关的session，无论内容多么水，只要题目带microservice，必定报不上名，可见Microservice有多火。最喜欢其中一页。关于这个典故，可以参考this，此图适用于一切高大上的名字——技术有SOA，Agile，CLOUD，DevOps等等，古代有道，气，八卦等等。此类名词的最大特点就是 一解释就懂，一问就不知，一讨论就打架。
微服务的流行，Martin功不可没，这老头也是个奇人，特别擅长抽象归纳和制造概念，我觉的这就是最牛逼的markting啊，感觉这也是目前国人欠缺的能力。
Martin Fowler是国际著名的OO专家，敏捷开发方法的创始人之一，现为ThoughtWorks公司的首席科学家.福勒（Martin Fowler），在面向对象分析设计、UML、模式、软件开发方法学、XP、重构等方面，都是世界顶级的专家，现为Thought Works公司的首席科学家。Thought Works是一家从事企业应用开发和集成的公司。早在20世纪80年代，Fowler就是使用对象技术构建多层企业应用的倡导者，他著有几本经典书籍： 《企业应用架构模式》、《UML精粹》和《重构》等。—— 百度百科
先来看看传统的web开发方式，通过对比比较容易理解什么是Microservice Architecture。和Microservice相对应的，这种方式一般被称为Monolithic（比较难传神的翻译）。所有的功能打包在一个 WAR包里，基本没有外部依赖（除了容器），部署在一个JEE容器（Tomcat，JBoss，WebLogic）里，包含了 DO/DAO，Service，UI等所有逻辑。
Monolithic比较适合小项目，优点是：
- 开发简单直接，集中式管理
- 基本不会重复开发
- 功能都在本地，没有分布式的管理开销和调用开销
它的缺点也非常明显，特别对于互联网公司来说（不一一列举了）：
- 开发效率低：所有的开发在一个项目改代码，递交代码相互等待，代码冲突不断
- 代码维护难：代码功能耦合在一起，新人不知道何从下手
- 部署不灵活：构建时间长，任何小修改必须重新构建整个项目，这个过程往往很长
- 稳定性不高：一个微不足道的小问题，可以导致整个应用挂掉
- 扩展性不够：无法满足高并发情况下的业务需求
所以，现在主流的设计一般会采用Microservice Architecture，就是基于微服务的架构。简单来说， 微服务的目的是有效的拆分应用，实现敏捷开发和部署 。
用《The art of scalability》一书里提到的scale
REST真的完全适合微服务架构吗？
【编者的话】作者根据自己的微服务经验，提出REST并不是微服务的唯一通信机制，从而介绍了微服务的几种通信机制，包括REST、管道以及基于异步消息传递。同时，作者提出了在不同的场景下可以使用不同的通信机制。
在我接触微服务的这段时间，大部分关于如何安装部署微服务的线上样例或文章都一致认为REST是微服务之间通信的唯一方式。因此，你可能理所当然地认为REST就是微服务的一种标准，并且是设计与实现微服务系统一种方式。然而，并非如此。…
近期评论