微服务 之 服务拆分

软件工程

• IEEE定义: 将系统化的、规范的、可度量的方法用于软件的开发、运行和维护的过程

• 软件工程 VS 计算机科学与技术

软件架构

• 软件架构实质是 将软件分解成元素 以及 定义这些元素之间的关系

• 软件架构决定了软件的非功能性能力 包括: 可维护性、可测试性、可扩展性以及可部署性

单体架构

• Laravel && Django

• 视图层 => 多平台、多应用、时效性

• 逻辑控制层 => 和数据持久层紧耦合

• 数据持久层 => 和逻辑控制层紧耦合

微服务架构

• 服务是一个单一的、可独立部署的软件组件

• 微服务架构的最核心特性是服务之间的松耦合性

• 服务的大小并不重要

微服务架构的基础是单体架构

服务拆分

• 根据业务能力进行服务拆分

• 根据子域进行服务拆分 (Domain Driven Design, DDD)

• 服务拆分的指导原则

单一职责原则 (Single Responsibility Principle，SRP) 定义的每一个类都应该只有一个职责 因此也就只有一个理由对它进行修改

遵循闭包原则 (Common Closure Principle，CCP) 如果对包做出修改，需要调整的类应该都在这个包之内

• 服务拆分的难点问题

网络延迟

同步进程间通信导致可用性降低

在服务之间维持数据一致性

获取一致的数据视图

上帝类阻碍了拆分

机械指挥官

• saas-tenant

git rev-list --max-parents=0 HEAD

# https://gitlab.zeaho.com/php/saas-tenant
git show c0ccc2924b710ce39ff2884ddc64bf66765c0797
# Date: Sat Aug 4 22:30:45 2018 +0800

# https://gitlab.zeaho.com/php/saas-deprecated
git show fa75dbb809b9c425ef8ebd8a1b63fb771d0ec4c2
# Date: Tue Jan 17 15:58:27 2017 +0800

• saas-analyze

项目拆分 => 服务拆分 => 数据库拆分 => (人事)组织拆分

数据一致性 <= 报表重算

通信可靠性 <= 消息中间件

网络延迟 <= 数据接口超时

调试监控 <= 拥抱DevOps

参考

• 带你读《微服务架构设计模式》之二：服务的拆分策略

• 四种软件架构，看看你属于哪个层次