1 单体应用架构图举例:
2、微服务架构图举例:
微服务,服务调用基本组件:
服务描述,注册中心,服务框架,服务追踪,服务治理
3 、 单体应用与微服务架构优缺点
单体应用有如下优点:
- 为人所熟知:现有的大部分工具、应用服务器、框架和脚本都是这种应用程序;
- IDE友好:像 NetBeans、Eclipse、IntelliJ 这些开发环境都是针对开发、部署、调试这样的单个应用而设计的;
- 便于共享:单个归档文件包含所有功能,便于在团队之间以及不同的部署阶段之间共享;
- 容易部署:只需将单个归档文件复制到单个目录下。
- 方便调试,代码都在一起;
- 没有分布式开销,所有服务都在本地容器内;
- 中小型项目可以快速迭代,不需要太多资源。
单体应用的一些不足:
- 不够灵活:对应用程序做任何细微的修改都需要将整个应用程序重新构建、重新部署。开发人员需要等到整个应用程序部署完成后才能看到变化。如果多个开发人员共同开发一个应用程序,那么还要等待其他开发人员完成了各自的开发。这降低了团队的灵活性和功能交付频率;
- 妨碍持续交付:单体应用可能会比较大,构建和部署时间也相应地比较长,不利于频繁部署,阻碍持续交付。在移动应用开发中,这个问题会显得尤为严重;
- 受技术栈限制:对于这类应用,技术是在开发之前经过慎重评估后选定的,每个团队成员都必须使用相同的开发语言、持久化存储及消息系统,而且要使用类似的工具,无法根据具体的场景做出其它选择;
- 技术债务:“不坏不修(Not broken,don’t fix)”,这在软件开发中非常常见,单体应用尤其如此。系统设计或写好的代码难以修改,因为应用程序的其它部分可能会以意料之外的方式使用它。随着时间推移、人员更迭,这必然会增加应用程序的技术债务。
- 代码维护难:代码功能耦合高,新人不知道何从下手,维护比较困难;
- 开发效率低:所有的开发在一个项目改代码,递交代码相互等待,代码冲突不断;
微服务具有如下优点:
- 单独部署,独立开发,易于开发、扩展、理解和维护;
- 比单体应用启动快;
- 复杂性低,局部修改很容易部署,有利于持续集成和持续交付;
- 故障隔离,一个服务出现问题不会影响整个应用;
- 不会受限于任何技术栈。
- 微服务只是业务逻辑的代码,不会和HTML,CSS 或其他界面组件混合。
- 易于和第三方应用系统集成。
微服务具有如下缺点:
- 需要分布式事务的支持;
- 效率相对低,团队依赖强,一个服务的版本延迟会拖慢整个应用的开发周期
- 开发难度大;垮服务的调用通常是不同的机器,甚至是不同的机房,开发人员需要处理超时、网络异常等问题
- 分布式系统比单体应用架构复杂,随着服务数量增加,管理复杂性增加,极大地增加运维工作量;
- 故障诊断比较难,不容易定位错误节点;
4、单体应用和微服务各适用的业务场景
单体应用适合场景:
- 业务场景简单
- 创业团队,项目初期等场景,需要快速开发迭代
微服务适合场景:
- 业务场景复杂,核心业务可以独立
- 业务量大
5、业务开发中单体应用过渡膨胀带来的问题
- 数据量大,散落各处,取值不便
- 牵一发动全身,迭代艰难
6、应从哪些角度去进行微服务拆分
- 纵向拆分:从业务维度进行拆分。拆分标准按照业务的关联程度来决定,关联比较密切的业务适合拆分成为一个微服务,功能相对比较独立的业务适合拆分为一个微服务。
- 横向拆分:从公共且独立功能的维度进行拆分。拆分标准是按照是否有公共的被多个其他服务调用,且依赖的资源独立,不与其他业务耦合。
- 服务化拆分的前提条件:
-
- 服务如何定义,包括通讯协议,接口描述
-
- 服务如何发布和订阅(注册中心)
-
- 服务如何监控
-
- 服务如何治理
-
- 故障如何定位