单体架构的不足
1 便于开发，易于测试，易于部署，无法非模块，无法扩展，无法独立升级，io模块和cpu模块，可靠性差，小的模块内存泄露，大的bug,统一框架和语言，变更成本高，无法引入新的语言，代码修改，扩展麻烦，测试麻烦，可靠性，
2 复杂性，代码混乱，维护麻烦，交互效率低，编译，调试耗时间，容易冲突，bug难找，风险大，发布的频次低，版本更新慢，
微服务架构
1 解决非功能架构，高内聚，低耦合，不同放入语言和存储，
2 优势：易于开发和维护，启动和调试速度快，提高开发效率，独立部署，晚上访问量大，微服务的修改不需要协调其他的服务，减少沟通成本，代码到服务边界的影响，便于横向扩展和扩容，独立扩容，拆分小服务，系统级别的扩展，不同的团队维护，减少沟通的成本，不同的团队各司其职，独立负责某些服务，较少技术的，不同的技术，go,ES,redis,尝试新的技术变得容易，新的模块尝试新的技术，
3 api网关：身份验证，动态路由请求，数据的聚合，
微服务的挑战
1 服务的需要自己的额数据库，部署在共享的数据服务器，修改配置，自己的业务能力，了解自己的产品和业务，才能划分边界，高内聚和低耦合，
2 服务拆分：领域模型，组织架构，单一职责，事务的一致性，是咧在不同的服务器，事务的处理，分布式事务，延时性高，消息队列，事务操作尽量防止统一服务器，服务通信：分布式架构，协议？rbc,restapi负载？
http:学习门槛低，夸语言，便于调试，缺点：协议繁琐，文档不好维护，性能差，
rpc:基于tcp协议，dubbo等，rbc:代码提示，协议维护在代码里面，缺点：很多的rbc不支持夸语言，
服务注册表：端口，服务的名字，zk;负载均衡，
3 服务网关：身份验证，代码的复用性，流程控制，内网和外网的边界，日志统计，安全防御，，业务专注业务！！！服务网关不应该有过多的业务逻辑，高可观察，监控指标聚合输出到图表输出，分布式追踪，输入和输出，一个请求长，追踪！！！服务的依赖关系，服务降级：不可用，缓存展示或者其他，接口幂等性，
最佳实践
1 代码的脚手架，统一，搭建代码，
2 独立的数据库，降低耦合，共享库不应该包含业务，
soa和微服务
1 技术站不同，soa:共享的数据库，力度比较粗，多个单体的组合，微服务：独立的数据库，力度更小的服务，
标签：网关,架构,区别,代码,单体,模块,服务,rbc From： https://blog.csdn.net/m0_37871355/article/details/140432849