微服务的一些理解

微服务这一概念之前只是简单了解没有直接体会，近距离观察一段时间之后有了一些看法。

优点

将单一服务切分到微服务之后，容易与实际中的团队组织结构相对应。以服务为粒度，可以交由不同团队进行维护，彼此之间通过RPC等通信协议进行协作。在业务内容与人员都达到一定规模的场景下，这样的切分实际能够划定不同团队之间的工作边界，使得团队之间的协作不那么耦合。

单一系统遇到问题的时候很容易造成整体服务不可用，拆分微服务之后，很多问题只会在局部服务中出现，问题的影响范围可以得到控制，提升了系统整体的稳定性与可靠性。

服务拆分之后，局部的性能问题可以有更多的手段与策略进行优化。优化的成本与风险都会相较单一服务低。堆机器这种粗暴方案也能更有针对性。

如上所说单独的服务即使遇到问题，影响的范围也相对可控，因此更利于进行一些技术升级改造。当然，实际上的优化升级往往都是很漫长的过程，但那更多是愿不愿意改的问题，而不是敢不敢改的问题。

当系统的复杂性达到一定量级之后，微服务化不仅仅从资源层面可以让硬件资源针对部分服务进行适配，提升资源利用率。另一方面也可以降低系统维护复杂度，微服务自身的复杂度与系统整体的复杂度相比减轻了很多，对于维护的人员来说，可以筛减掉很多无需关心的内容。

原先可以在一处解决的问题，变成了一系列RPC调用。原本可能就是代码逻辑问题，现在则可能是RPC下游的服务可用性问题，RPC调用的网络问题。在问题排查定位上，需要关注的因素会更多。

单一服务很容易进行部署，微服务之后服务之间的依赖关系使得微服务的部署变得复杂。不同环境、不同版本所需部署的微服务都有各自的需求。

微服务之间的依赖关系，使得在某些服务升级变更的时候需要沟通上下游，增加了沟通协调成本。

不同服务之间的RPC调用肯定比本地的函数调用慢，网络调用开销的增加是不可避免的。如果服务链路过长，那么受到的影响就更明显了。

微服务的关键问题是如何进行划分，如何控制服务的粒度。服务切分得不好会带来后续一系列问题。如何切分这件事情和业务场景相关，也和实际人员的经验能力相关。

微服务之间的依赖关系需要以简明直接的方式进行展现，这样有利于在服务切分不合理的时候第一时间发现。

微服务之间的调用链路一定需要进行追踪，否则问题排查是无从进行的。

当微服务数量达到一定量级，局部出现问题总是无可避免的，这种情况下完善的监控预警就显得尤为重要了。否则在遇到问题时容易抓瞎。

微服务化之后也会继续出现新的业务逻辑与场景，这就意味着会继续微服务化。那么代码层面的一致性与底层框架公共服务的可用性、易用性就变得很重要了。

理论上微服务之后服务之间只要保证协议即可，使用什么语言都可以。但实际上需要进行控制，多语言的成本太高，完全没有必要。