传统的开发模式

单体式开发（Monolithic）

既所有的功能打包在一个 WAR 包里，基本没有外部依赖（除了容器），部署在一个 JavaEE 容器（Tomcat，JBoss，WebLogic）里，包含了 DO/DAO，Service，UI 等所有逻辑。

优点

• 开发简单，集中式管理
• 基本不会重复开发
• 功能都在本地，没有分布式的管理和调用消耗

缺点

• 效率低：开发都在同一个项目改代码，相互等待，冲突不断
• 维护难：代码功功能耦合在一起，新人不知道何从下手
• 不灵活：构建时间长，任何小修改都要重构整个项目，耗时
• 稳定性差：一个微小的问题，都可能导致整个应用挂掉
• 扩展性不够：无法满足高并发下的业务需求

微服务架构

目的：有效的拆分应用，实现敏捷开发和部署

微服务特征

官方标准定义

• 一系列的独立的服务共同组成系统
• 单独部署，跑在自己的进程中
• 每个服务为独立的业务开发
• 分布式管理
• 非常强调隔离性

标准

• 分布式服务组成的系统
• 按照业务，而不是技术来划分组织
• 做有生命的产品而不是项目
• 强服务个体和弱通信（ Smart endpoints and dumb pipes ）
• 自动化运维（ DevOps ）
• 高度容错性
• 快速演化和迭代

SOA（Service-Oriented Architecture:面向服务的架构)架构与微服务架构的区别

微服务与 SOA 有很多相同之处。两者都属于典型的、包含松耦合分布式组件的系统结构。在围绕着服务的概念创建架构这一方面，微服务提供了一种更清晰、定义更良好的方式。微服务的原则与敏捷软件开发思想是高度一致的，而它与 SOA 原则的演化的目标也是相同的，则减少传统的企业服务总线开发的高复杂性。两者之间最关键的区别在于，微服务专注于以自治的方式产生价值。但是两种架构背后的意图是不同的：SOA 尝试将应用集成，一般采用中央管理模式来确保各应用能够交互运作。微服务尝试部署新功能，快速有效地扩展开发团队。它着重于分散管理、代码再利用与自动化执行。