首先，让我们来看看单体体系结构和微服务的比较
单体架构
在这种情况下，lkdhf公司还在创业的时候，或者前期用户确定并不多的时候，可以降低成本，更快地上线，前期功能也不是特别复杂，所以我认为采用单体架构就可以满足需求。 在没有复杂的业务和大流量之前，不需要上升，需要用各种各样的感觉新鲜又贵的东西。
单体体系结构的好处：
开发简洁，功能全在一个程序内，便于软件设计和开发规划。 部署简单、程序单一、没有分布式群集的复杂部署环境降低了部署难度。 易于测试，无复杂的服务呼叫关系，均便于内部呼叫测试。 当然，前期的时候，成本、业务的复杂度不高，考虑到迅速上线，我很满意。 然后业务量逐渐增加了。 系统也变大了，重新编译启动的时间也越来越长了。 一个功能的修正需要全面的回归测试，一不小心给人一个意想不到的惊喜，现在需要另一个基本独立的系统。 这个时候，还是考虑用原来的单体体系结构来修改这样的系统，取而代之的是软件维护和迭代更新的无限痛苦。
由于单个APP应用程序就像一个大容器一样，有很多服务，而且关系密切，因此APP应用程序在扩展时必须以“APP应用程序”为单位进行扩展。
如果一个业务模块的负载太高，则无法单独扩展服务，需要扩展整个APP应用程序，这可能会浪费资源。
此外，单体APP应用由于服务之间的紧密性、依赖性过高，难以测试、升级，开发曲线后期大幅上升，开发可能会变得困难。 相比之下，「微服务架构」可以解决这个问题。
微服务架构
什么是微服务体系结构？
1 .微服务(Microservices Architecture )是一种架构类型，其中大型复杂的软件APP应用由一个或多个微服务组成。 系统中的各个微服务可以独立部署，各个微服务之间是松散耦合的。 每个微服务只关注完成一个任务，并成功完成该任务。 每个微服务都有自己的业务能力。 例如，按商品、购物车、订单等业务边界进行服务分割，另一个，系统中存在的具有共性的基础服务，例如邮件、邮件、日志等，分割为单独的服务，作为基础服务层复用到上位服务中
2 .微服务是指开发单一的小型、具有独立业务功能的服务，每项服务都有自己的处理和轻量通信机构，可以部署在单一或多个服务上。
3 .微服务也是指松散耦合、具有一定有界上下文的面向服务的体系结构。 也就是说，如果同时修改所有服务，则它们是紧密耦合的，因此如果需要了解服务(而不是微服务)过多的上下文场景的使用条件，则它们是有上下文边界的服务。
微服务的优点：
1、技术异构
根据服务不同，内部的开发技术也可以不一致。 也可以用java开发服务a，用谷歌开发服务b。 不用用哪个语言是世界上的好语言来讨论。 微服务体系结构-多技术可以为每个服务选择适合该服务的技术，并在系统的不同部分使用不同的存储技术。 例如，a服务可以选择redis存储，b服务可以选择MySQL存储。 这都是允许的，你的服务可以由你决定。
2、隔离性
即使一个服务不可用，另一个服务也不会停机。 因为各项服务是相互独立的自律系统。 这是单体APP应用程序所不能做到的。 作为单体APP应用程序的模块将关闭，整个系统将无法使用。 当然，单个程序也可以在不同的计算机上部署相同的程序来实现备份，但也存在上述资源浪费的问题。
3、可扩展性
在大型单元服务中，如果出现性能瓶颈，则只有扩展整个软件，而实际上可能影响性能的模块之一，而且升级整个APP应用程序的成本也很高。 这在微服务体系结构中得到了改进。 只能扩展升级影响性能的服务。 这样对症治疗的效果很好。
4、简化部署
您的服务是一个巨大的单机服务，有几百万行代码，修改几行代码也很明显重新编译整个APP应用程序很麻烦。 此外，软件更改带来的不确定性非常高，软件部署的影响也非常大。 在微服务体系结构中，每项服务的部署都是独立的，即使实际发生问题，只要影响单个服务，就可以快速回滚和解决版本。
5、易优化
由于微服务体系结构中单个服务的代码量不是很大，因此如果lkdhf需要重构或优化这部分服务，它将变得相当容易。 代码量越少，原本就意味着代码变更带来的影响越小。 在团队开发任务中，通过划分业务功能，各模块之间只需要做自己的事就可以了，减少了代码冲突和后维护时出现的联动问题。
微服务的缺点：
微服务APP应用程序是分布式系统，这一事实带来了复杂性。
1 .微服务体系结构可能带来过度操作，分布式系统可能复杂且难以管理。 微服务之间以REST、RPC等形式进行交互，为了考虑调用方的故障、过载、消息丢失等各种异常，需要编写代码来处理某些故障。 代码逻辑更复杂，因为请求的目标可能很慢或不可用。
2 .分布式配置跟踪问题较难，服务数量增加后，管理变得复杂
性增加, 由于系统由多个微服务构成, 需要一个设计良好的监控系统对各个微服务运行状态进行监控, 需要DevOps技巧。3. 微服务之间的事物性操作, 比如在涉及到微服务A和微服务B, 2个微服务都需要对不同的数据库进行操作, 则将无法通过数据库本身的事物机制保持一致, 如其中一个微服务失败或者出现异常, 则需要对事物一致性进行处理, 需要引入二阶段提交技术。