微服务架构问题分析

微服务在常规项目中，抽取了配置中心、注册中心 实现微服务集群及统一配置。微服务提倡进一步拆解单体应用的业务功能，但是在拆解的过程中会产生如下问题：

1.服务对外服务接口分散在各个微服务中，接口过于分散。

解决：引入网关概念，通过网关聚合各服务接口，提供对外统一接口

2.服务间调用链路复杂，发生问题时不好排查。

解决：引入链路跟踪概念，将调用链路关联起来，提供traceId等

3.由于业务功能拆分可能导致的事务问题

解决：引入分布式事务概念，基于三方事务管理实现事务状态统一

4.微服务众多，部署及运维成为难题

解决：引入k8s，cicd 等概念结合devops，降低部署及运维难度

5.拆分微服务后，基础设施众多，服务众多，对于硬件要求极大的提高，成本相较单体应用有所提升

解决：自建无法解决。引入云概念，采购云服务，通过云服务的方式解决基础设施的部署及运维问题，相应的成本成为了新的问题。

6.微服务开发语言对于内存及CPU的占用等问题

解决：java GraalVM提出了native概念，降低对内存的占用，但目前还不是太成熟

Go语言相比较java内存占用更低

java 没有更简单的解决方案前，只能接受现状

7.服务之间严重依赖，避免由于某个服务崩溃导致服务雪崩

解决：引入了熔断的概念

微服务架构同样具有以下优点：

1.分解单体应用庞大臃肿的代码体积，专注于微服务提供的业务能力，便于部分功能迭代升级

2.微服务可以根据不同的需求分配不同的硬件配置

3.可以根据微服务的压力更便捷的实现扩展，提供更强的负载能力

4.微服务使用http等网络传输协议连接，可以实现不同语言的异构（虽然还没见过，但是感觉好厉害）

总结

对于企业面对业务庞大、复杂且需要频繁更新迭代的情况，微服务架构体系会体现更高效的迭代、部署能力，相应企业会愿意为微服务架构体系的基础设施环境买单。但对于个人及小型业务系统来说，基于开发、运维、硬件成本来说，还是单体应用架构更适合自身情况。