Java中微服务架构与传统架构的区别
在聊微服务之前，先来看看传统架构的优缺点。
传统的 MVC 架构，所有的子系统都集成在一个很繁杂的 JVM 进程中。
优点：
这种单体架构的优点在于方便管理，所有代码在同一项目中，但是当需求越来越多，项目规模越来越大，其坏处也很明显。
缺点：
1、项目过于臃肿，部署效率低下
当大大小小的功能模块都集中在同一项目的时候，整个项目必然会变得臃肿，让开发者难以维护。单体应用的代码越来越多，依赖的资源越来越多时，应用编译打包、部署测试一次非常耗时。系统高可用性差，资源无法隔离，整个单体系统的各个功能模块都依赖于同样的数据库、内存等资源，一旦某个功能模块对资源使用不当，整个系统都会被拖垮。
2、开发成本高
早期在团队开发人员只有两三个人的时候，协作修改代码，打包部署，更新发布这完全可以控制。但是团队一旦扩张，还是按照早期的方法去开发，那如果测试阶段只要有一块功能有问题，就得重新编译打包部署。所有的开发人员又都得参与其中，效率低下，开发成本极高。
3、无法灵活拓展
当系统的访问量越来越大的时候，单体系统固然可以进行水平扩展，部署在多台机器上组成集群：但是这种扩展并非灵活的扩展，因此，急需一种方法将应用的不同模块进行解耦，从而降低开发和部署成本。
要解决上面单体应用的问题，就必须引入服务化的概念。
什么是服务化？
用通俗的语言来说，服务化就是把传统单体应用中通过 JAR 包依赖产生的本地方法调用，改造成 RPC 接口产生的远程方法调用。这些服务是围绕业务功能构建的，可以通过全自动部署机制独立部署。 这些服务的集中管理最少，可以用不同的编程语言编写，并使用不同的数据存储技术。
什么是微服务？
微服务架构是一种架构风格和架构思想，它倡导我们在传统软件应用架构的基础上，将系统业务按照功能拆分为更加细粒度的服务，所拆分的每一个服务都是一个独立的应用，这些应用对外提供公共的API，可以独立承担对外服务的职责，通过此种思想方式所开发的软件服务实体就是“微服务”，而围绕着微服务思想构建的一系列结，我们可以将它称之为“微服务架构
微服务有什么样的具体特点呢？
1、服务拆分粒度更细
微服务可以说是更细维度的服务化，小到一个子模块，只要该模块依赖的资源与其他模块都没有关系，那么就可以拆分为一个微服务。
2、服务独立部署
传统的单体架构是以整个系统为单位进行部署，而微服务则是以每一个独立组件为单位进行部署。
3、服务独立维护，分工明确
每个微服务都可以交由一个小团队进行开发，测试维护部署，并对整个生命周期负责，当我们将每个微服务都隔离为独立的运行单元之后，任何一个或者多个微服务的失败都将只影响自己或者少量其他微服务，而不会大面积地波及整个服务运行体系。
微服务它是由单体应用进化到服务化拆分部署,后期随着移动互联网规模的不断扩大,敏捷开发、DevOps 理论的发展和实践。随着微服务架构的越来越完善和发展，更多的企业已经使用这种架构方法。
更多最新java技术，资料和知识点，可以私信或评论联系我领取！