|
微服务架构的重要特征
-
整个应用程序被拆分成相互独立但包含多个内部模块的子进程
-
与模块化的单体应用（Modular Monoliths）或 SOA 相反，微服务应用程序根据业务范围或领域垂直拆分。
-
微服务边界是外部的，微服务之间通过网络调用（RPC 或消息）相互通信。
-
微服务是独立的进程，它们可以独立部署。
-
它们以轻量级的方式进行通信，不需要任何智能通信通道。
微服务架构的优点
-
更好的开发规模
-
更快的开发速度
-
支持迭代开发或现代化增量开发
-
充分利用现代软件开发生态系统的优势（云、容器、 DevOps、Serverless）
-
支持水平缩放和细粒度缩放
-
小体量，较低了开发人员的认知复杂性
微服务架构的缺点
-
更高数量级的活动组件（服务、数据库、进程、容器、框架）
-
复杂性从代码转移到基础设施
-
RPC 调用和网络通信的大量增加
-
整个系统的安全性管理更具有挑战性
-
整个系统的设计变得更加困难
-
引入了分布式系统的复杂性
何时使用微服务架构
-
大规模 Web 应用开发
-
跨团队企业级应用协作开发
-
长期收益优先于短期收益
-
团队拥有能够设计微服务架构的软件架构师或高级工程师
2. 微服务架构的设计模式
独享数据库（Database per Microservice）
当一家公司将大型单体系统替换成一组微服务，首先要面临的最重要决策是关于数据库。单体架构会使用大型中央数据库。即使转移到微服务架构许多架构师仍倾向于保持数据库不变。虽然有一些短期收益，但它却是反模式的，特别是在大规模系统中，微服务将在数据库层严重耦合，整个迁移到微服务的目标都将面临失败（例如，团队授权、独立开发等问题）。
更好的方法是为每个微服务提供自己的数据存储，这样服务之间在数据库层就不存在强耦合。这里我使用数据库这一术语来表示逻辑上的数据隔离，也就是说微服务可以共享物理数据库，但应该使用分开的数据结构、集合或者表，这还将有助于确保微服务是按照领域驱动设计的方法正确拆分的。
（编辑：常州站长网）
【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!
|
