软件架构与设计模式_软件架构有几种

在上图中，应用调用一个中央API，将调用转发给正确的微服务。在此示例中，有为用户配置文件、库存、订单和付款提供单独的服务。我们可以想象这是一个用户订购应用。单独的微服务也可以相互调用。例如，支付服务可以在支付成功时通知订单服务。然后，订单服务可以调用库存服务来调整库存。

没有明确规定微服务有多大。在前面的示例中，用户配置文件服务可能负责用户的用户名和密码等数据，也可能负责家庭地址、头像图像、收藏夹等，也可以选择将所有这些责任分成更小的微服务。

优势

• 我们可以单独编写、维护、部署微服务
• 微服务架构容易扩展
• 重写变得很容易，因为微服务之间松耦合

劣势

• 实际上没有合适的工具平台，反而在最初编写结构良好的一体化应用，再拆分为微服务的办法实际上更容易。使用微服务，会产生许多额外的问题：通信、协调，向后兼容、日志记录等。没有编写结构良好的整体结构的必要技能的团队可能很难编写一组良好的微服务。
• 传统微服务架构可能会有多个失败点，查找问题可能会比较复杂

适用于

• 某些组件被密集使用并需要扩展的应用
• 为其他应用提供功能的应用
• 一体化架构下很复杂的应用
• 能够明确定义bounded contexts的应用

总结

各种软件架构模式很多时候会结合起来使用，他们之间并没有我们想象得那么水火难容。换句话说，没有万能的软件架构模式，如何选择取决于我们对于解决方案利弊的权衡。

关于Rainbond

当下，已经有很大一部分公司完成了单体架构向微服务架构的迁移改造，并在疲于应对大量微服务间通信问题时，开始考虑采用Service Mesh微服务架构作为服务与服务直接通信的透明化管理框架，以插件式的方式实现各种业务所需的高级管理功能。

而开源PaaS Rainbond提供了开箱即用的Service Mesh微服务架构，部署在Rainbond上的应用原生即是Service Mesh微服务架构应用。