MSA 特征

• 组件以服务形式提供——正如其名，微服务也是面向服务的。
• 围绕业务功能进行组织——微服务更倾向于围绕业务功能对服务结构进行划分、拆解。这样的服务，是针对业务领域有着完整实现的软件，它包含接口、持久存储以及对应的交互。
• 产品不是项目——微服务要求开发团队对软件产品的整个生命周期负责。
• 强化终端及弱化通道——微服务的应用致力于松耦合和高内聚，它们更喜欢简单的 REST 风格，而不是复杂的协议。或者采用轻量级消息总线来发布消息。
• 分散治理——微服务把整体式框架中的组件拆分成不同的服务。
• 分散数据管理——微服务让每个服务管理自己的数据库：无论是相同数据库的不同实例，或者是不同的数据库系统。
• 基础设施自动化——微服务更加依赖于基础设施自动化。
• 容错性设计——微服务应为每个应用的服务及数据中心提供日常的故障检测和恢复。
• 改进设计——微服务所提供的服务应该能够替换或者报废。

二、MSA 与 SOA

通常传统的 SOA 意味着大而全的单体架构的解决方案。这让设计、开发、测试、发布都增加了难度，其中任何细小的代码变更，都将导致整个系统需要重新测试、部署。而微服务架构恰恰把所有服务都打散，设置合理的颗粒度，各个服务间保持低耦合，每个服务都在其完整的生命周期中存活，将互相之间的影响降到最低。
　　SOA 需要对整个系统进行规范，而 MSA 的每个服务都可以有自己的开发语言、开发方式、灵活性大大提高。

1. SOA 架构的优点和缺点

优点：

• 1.易于开发——当前开发工具和 IDE 的目标就是支持这种一体应用的开发。
• 2.易于部署——只需要将 WAR 文件或目录结构放到合适的运行环境下即可。
• 3.易于伸缩——只需要在负载均衡器下面运行应用的多份副本就可以伸缩。

缺点：

• 1.代码库庞大——代码库的体积越来越大，新人来到团队会有恐惧感。应用也变得越来越难于理解和修改，开发效率降低。模块化也随着时间变化慢慢被破坏。因为难于理解如何实现变更，代码质量也会逐渐下降。这就成了个恶性循环！
• 2.IDE 超载——代码体积越大，IDE 越慢，开发效率越低。
• 3.Web 容器超载——应用越大，容器启动时间越长。开发者大量的时间浪费在等待容器的启动上。这也会影响到部署。
• 4.难于持续部署——对于频繁部署，巨大的单体架构也是个问题。
• 5.难于伸缩应用——单体应用只能在一个维度伸缩，不能独立地伸缩各个组件。
• 6.难于调整开发规模——单体应用对调整开发规模也是个障碍。它会阻碍组织团队相互独立的工作。
• 7.需要对一个技术栈长期投入——单体架构迫使你采用开发初期选择的技术栈，如果要采用新的平台框架，需要重写整个应用，这样就太冒险了。

2. 微服务架构的优点和缺点

微服务架构的诞生正是解决单体架构的缺点。一个微服务架构的应用是多层架构的或是六角架构的，并且包含多种类型的组件：

• 1.表示组件——响应处理 HTTP 请求，并返回 HTML 或 JSON 或 XML。
• 2.业务逻辑——应用的业务逻辑。
• 3.数据库访问逻辑——数据访问对象用于访问数据库。
• 4.应用集成逻辑——消息层。
  　　这些逻辑组件分别响应应用中不同的功能模块。
  　　优点：
• 1.每个微服务都相对较小。易于开发者理解；IDE 反应更快；Web 容器启动更快。
• 2.每个服务都可以独立部署，易于频繁部署新版本的服务。
• 3.易于伸缩开发组织结构。每个团队可以独立于其它团队开发、部署和伸缩服务。
• 4.提升故障隔离。一个服务出现故障，只有该服务受影响。
• 5.每个服务可以单独开发和部署。
• 6.消除了任何技术栈的长期投入。
  　　缺点：
• 1.开发者要处理分布式系统的额外复杂度。
• 2.测试更加困难。
• 3.开发者需要实现服务间通信机制。
• 4.不使用分布式事务实现跨服务的用例更加困难。
• 5.实现跨服务的用例需要团队间的细致协作。
• 6.生产环境的部署复杂度高，对于包含多种服务类型的系统，部署和管理的操作复杂度仍然存在。
• 7.内存消耗增加。

三、何时采用 MSA

微服务使开发变得更简单、更快捷了。但是，微服务带来一系列的非功能性需求，比如说事务、服务治理（注册，发现，负载，路由，认证授权，隔离）、监控（日志，性能监控，告警，调用链路）、部署、测试等。微服务依赖于“基础设施自动化”。