软件开发不是一个定义、执行的线性过程,而是一个不断演化的过程
软件开发时,难以保证客户需求的变更、增改,所以沟通、学习、开发、测试、交付等过程贯穿全程
因此,本篇文章需要讨论的是如何更好的解决上诉问题
一、传统应用
传统应用开发时,一般采用的是瀑布模型(先把所有的需求沟通好,从上而下像瀑布一样开发)
会存在以下问题:
1.功能模块之间紧耦合
各个功能模块之间调用是通过代码层面而不是接口或者协议调用,这样造成了模块之间耦合度太高,当修改了A模块,那么极有可能造成调用者B模块的运行异常。
同时,模块直接耦合度太高,不利于扩展、维护、测试
2.数据库修改不便
因为是单体应用,所以一般都是使用一个数据库,虽然不同的功能模块使用了各自的业务表,但是有些时候为了编码方便,多表之间可能存在业务关联。因此,当为了A这个模块的功能修改了数据库表字段,有可能引起B这个模块的业务功能报错,那么每次对字段的修改,都可能造成对整个系统的测试,增加成本
3.维护不便
因此代码都是在一个应用程序中,因此只要修改了其中一小部分功能,那么整个系统都需要重新编译、测试、打包运行增加的成本可想而知
二、微服务架构
1.有约束
程序即服务,每个服务只做一件事,做好一件事
把原来单体应用中的功能模块拆分为一个个独立的服务程序
2.服务独立
因为每个服务只需完成自己的业务职责,因此当业务变动时,只需要更新此服务,而不用更新全部服务
3.数据库独立
每个微服务有自己的数据库,对数据的操作通过服务提供的接口完成,避免了直接操作数据库
4.松耦合
服务之间调用或者通信是通过接口完成的,所以只要接口参数没有变化,那么服务内部的业务功能可自由调理