从单体应用到服务化结构 分享整理

2018-11-15 香格里拉 从单体应用到服务化结构 会后总结整理

首先,这个内容很高大上,很有挑战性,我根本不会,以前了解的也接近于零,此处只是整理会上的梳理和让自己有此部分内容有个基本概念和记录,以便在之后可能会用到和学习.

会议核心内容概括:

1.单体应用架构的局限性

2.服务化架构解决方案(尝试中)

3.服务化中遇到的挑战

一 单体应用

单体应用概念：在项目中只需要通过引用把所有的功能集中在同一系统中实现 

二 单体应用的优点

（1）易于开发：开发人员使用当前开发工具在短时间内就可以开发出单体应用.（IDE友好）

（2）易于测试：因为不需要依赖其他接口，测试可以节约相当多时间了。

（3）易于部署：你只需要将目录部署在运行环境中即可

三 单体应用的缺陷

(1) 发布构建缓慢
(2) 代码库巨大,冗余代码越来越多;业务职责越来越模糊,反正知道表在哪里就OK了,一个sql语句搞定了,那么这个时候还需要进行更加复杂的工作,在细分职责吗? (由此引发的问题)
(3) 相同的业务在不同应用中存在不一致的问题
(4) 业务模块之间的依赖混乱
(5) 某个业务模块有问题,会导致整个应用停止服务?
(6) 扩展能力受限,只能对整个应用进行扩展,不能针对不同模块特性进行扩展(计算密集型和IO密集型)
(7) 对现有模块的依赖太严重,难以引入新的技术.

四 对现有问题的解决办法

• publiccode抽象公共业务组件
• extapi提供数据接口
• 数据同步,数据依赖

五 服务化能带来什么

• 松耦合
• 业务内聚，易于重用
• 独立开发，测试，部署和发布
• 快速迭代
• 故障隔离，易于服务降级
• 服务易于扩展，灵活性高
• 平台不相关，利于创新

六 服务化过程中可能遇到的挑战

• 服务划分
• 服务治理
• 分布式事务
• 自动化部署体系devops
• 团队组织的调整
• 人员的技术能力提升

七 服务化的必要性

• 快速试错性产品不适合做服务化
• 公共业务和基础设施服务可以做服务化
• 业务不断的发展后，必然需要服务化

声明: 以上内容来源于

1. 单体架构与微服务架构博客
2. 结构初识
3. 云客杨小松分享会上内容整理

本作品采用《CC 协议》，转载必须注明作者和本文链接