微服务和传统应用对比

软件开发不是一个定义、执行的线性过程，而是一个不断演化的过程

软件开发时，难以保证客户需求的变更、增改，所以沟通、学习、开发、测试、交付等过程贯穿全程

因此，本篇文章需要讨论的是如何更好的解决上诉问题

一、传统应用

        传统应用开发时，一般采用的是瀑布模型（先把所有的需求沟通好，从上而下像瀑布一样开发）

        会存在以下问题：

        1.功能模块之间紧耦合

                各个功能模块之间调用是通过代码层面而不是接口或者协议调用，这样造成了模块之间耦合度太高，当修改了A模块，那么极有可能造成调用者B模块的运行异常。

                同时，模块直接耦合度太高，不利于扩展、维护、测试

        2.数据库修改不便

                因为是单体应用，所以一般都是使用一个数据库，虽然不同的功能模块使用了各自的业务表，但是有些时候为了编码方便，多表之间可能存在业务关联。因此，当为了A这个模块的功能修改了数据库表字段，有可能引起B这个模块的业务功能报错，那么每次对字段的修改，都可能造成对整个系统的测试，增加成本

        3.维护不便

        因此代码都是在一个应用程序中，因此只要修改了其中一小部分功能，那么整个系统都需要重新编译、测试、打包运行增加的成本可想而知

二、微服务架构

        1.有约束

                程序即服务，每个服务只做一件事，做好一件事

                把原来单体应用中的功能模块拆分为一个个独立的服务程序

        2.服务独立

                因为每个服务只需完成自己的业务职责，因此当业务变动时，只需要更新此服务，而不用更新全部服务

        3.数据库独立

                每个微服务有自己的数据库，对数据的操作通过服务提供的接口完成，避免了直接操作数据库

        4.松耦合

                服务之间调用或者通信是通过接口完成的，所以只要接口参数没有变化，那么服务内部的业务功能可自由调理