微服务，服务调用基本组件：
服务描述，注册中心，服务框架，服务追踪，服务治理

单体应用有如下优点：

• 为人所熟知：现有的大部分工具、应用服务器、框架和脚本都是这种应用程序；
• IDE友好：像 NetBeans、Eclipse、IntelliJ 这些开发环境都是针对开发、部署、调试这样的单个应用而设计的；
• 便于共享：单个归档文件包含所有功能，便于在团队之间以及不同的部署阶段之间共享；
• 容易部署：只需将单个归档文件复制到单个目录下。
• 方便调试，代码都在一起；
• 没有分布式开销，所有服务都在本地容器内；
• 中小型项目可以快速迭代，不需要太多资源。

单体应用的一些不足：

• 不够灵活：对应用程序做任何细微的修改都需要将整个应用程序重新构建、重新部署。开发人员需要等到整个应用程序部署完成后才能看到变化。如果多个开发人员共同开发一个应用程序，那么还要等待其他开发人员完成了各自的开发。这降低了团队的灵活性和功能交付频率；
• 妨碍持续交付：单体应用可能会比较大，构建和部署时间也相应地比较长，不利于频繁部署，阻碍持续交付。在移动应用开发中，这个问题会显得尤为严重；
• 受技术栈限制：对于这类应用，技术是在开发之前经过慎重评估后选定的，每个团队成员都必须使用相同的开发语言、持久化存储及消息系统，而且要使用类似的工具，无法根据具体的场景做出其它选择；
• 技术债务：“不坏不修（Not broken，don’t fix）”，这在软件开发中非常常见，单体应用尤其如此。系统设计或写好的代码难以修改，因为应用程序的其它部分可能会以意料之外的方式使用它。随着时间推移、人员更迭，这必然会增加应用程序的技术债务。
• 代码维护难：代码功能耦合高，新人不知道何从下手，维护比较困难；
• 开发效率低：所有的开发在一个项目改代码，递交代码相互等待，代码冲突不断；

微服务具有如下优点：

• 单独部署，独立开发，易于开发、扩展、理解和维护；
• 比单体应用启动快；
• 复杂性低，局部修改很容易部署，有利于持续集成和持续交付；
• 故障隔离，一个服务出现问题不会影响整个应用；
• 不会受限于任何技术栈。
• 微服务只是业务逻辑的代码，不会和HTML,CSS 或其他界面组件混合。
• 易于和第三方应用系统集成。

微服务具有如下缺点：

• 需要分布式事务的支持；
• 效率相对低，团队依赖强，一个服务的版本延迟会拖慢整个应用的开发周期
• 开发难度大；垮服务的调用通常是不同的机器，甚至是不同的机房，开发人员需要处理超时、网络异常等问题
• 分布式系统比单体应用架构复杂，随着服务数量增加，管理复杂性增加，极大地增加运维工作量；
• 故障诊断比较难，不容易定位错误节点；

单体应用适合场景：

• 业务场景简单
• 创业团队，项目初期等场景，需要快速开发迭代

微服务适合场景：

• 业务场景复杂，核心业务可以独立
• 业务量大

• 数据量大，散落各处，取值不便
• 牵一发动全身，迭代艰难

• 纵向拆分：从业务维度进行拆分。拆分标准按照业务的关联程度来决定，关联比较密切的业务适合拆分成为一个微服务，功能相对比较独立的业务适合拆分为一个微服务。
• 横向拆分：从公共且独立功能的维度进行拆分。拆分标准是按照是否有公共的被多个其他服务调用，且依赖的资源独立，不与其他业务耦合。
• 服务化拆分的前提条件：
• • 服务如何定义，包括通讯协议，接口描述
• • 服务如何发布和订阅（注册中心）
• • 服务如何监控
• • 服务如何治理
• • 故障如何定位