SpringCloud微服务带来的问题

业务团队的痛点 

1. 对于业务开发团队而言，最强的是技术吗？一定不是，业务团队最强的一定是对于业务的理解和熟悉程度。 

2. 而业务应用的核心价值，就是为了实现业务场景，而不是写微服务，微服务只是一种实现业务的手段。 

3. 业务团队除了关心业务之外，他们所面临的最大的挑战在于，如何保证系统的稳定性何可扩展性、如何设计一个安全的open api。如果对服务进行拆分、如何保证跨库的数据一致性。以及对于旧系统的改造。 

4. 于公司层面而言，业务团队的压力还来自于时间人力的投入，我们用于被各种deadline赶着走。所以作为一个业务程序员，如果在这个deadline之前还需要花更多的时间投入在spring cloud这些工具的学习上，那无疑是雪上加霜。公司对于业务团队的考核，永远只看结果！ 

服务治理功能不齐全 

SpringCloud对于服务治理的功能是不够强大的，如果需要实现企业级的微服务落地以及服务治理，那么我们还需要基于SpringCloud这套体系上来解决这些问题。 

跨语言带来的问题 

微服务有一个很重要的特性，就是不同的微服务可以采用自己最擅长的语言来编写程序。这种特性在企业中落地的时候又会带来一些问题。 

比如公司内部会开发一些公共的类库或者框架，也或者会使用第三方的类库或者框架来实现某些功能。 

但是由于公司的微服务用了各种各样的语言，那意味着这些类库需要针对不同的语言开发兼容版本。如果是主流语言还好，如果是一些小众语言，那对于这些基础组件的开发者而言无疑是晴天霹雳 

总结 

从这些痛点中可以发现，我们所做的所有非业务类的事情，都是为了保证把请求发送到正确的地方，并且能够及时或得正确的结果。那对于对于业务开发人员而言，是否有必要去关心这些呢？ 

回到最开始我们说的一个例子，在进行计算机网络通信的时候，开发人员有必要去关心网络通信的细节吗？ 我们在使用http协议进行数据传输时，关心过底层是使用TCP还是udp？数据是怎么传输的？ 

既然我们不需要关心这些，那对于微服务架构中的这些问题，业务开发人员为什么一定要关心服务的通讯呢？ 

技术栈下沉 

那么对于微服务实施来说，能不能像网络协议的下沉一样，增加一个微服务层来完成这个而是情呢？这就引出了service mesh 

在每个服务中，会有一个service mesh实例，客户端发起一个请求，首先会把请求发送到本地的service mesh实例，service mesh实例中会完成完整的服务之间的调用流程，比如服务发现、负载均衡。最终发送给目标服务。而这个service mesh实例，专业名称应该为:sidecar , 简单来说，它是原有的客户端和服务端之间的一个代理 

在多个服务的调用中，这种通信方式的表现形式就像一个网格，sidecar之间的链接形成了一个网络，这个就是service mesh的由来 

Service Mesh为业务开发团队降低了门槛，提供了稳定的基础设施，最重要的是，让业务开发团队从微服务实现的具体技术细节中解放出来回归到业务。