今天谈一下关于微服务的几个关键的点。
首先是我们在实际的开发中是否一定要用相关的微服务框架？我个人的理解，只要你满足原来大的单体做了拆分，满足各个拆分后的组件之间通过轻量的HTTP REST做集成，它实际上就是微服务，当然用当前主流的，比如SpringCloud做开发当然更好。
第二个就是大家都比较关心的一个问题，就是微服务如何做拆分。不管是采用结构化的分析方法，基于实际的业务架构和数据架构，基于CRUD矩阵分析做聚合做拆分，还是基于当前的领域建模，通过事件风暴，通过基于对象的聚类，去识别限界上下文，然后再做聚合做拆分都是可以的。
但是微服务拆分的一个核心中心的重点还是拆分以后各个微服务之间能够做到尽量松耦合。同时这个拆分还跟业务系统的复杂度，团队架构模式相关。比如一个团队只有3-4个人，把业务拆分成8-9个微服务。这个时候一个人管理多个微服务时，前期实际上很难找到一个标准的管控规范控制各个微服务之间不发生错误的调用。比如微服务A不访问微服务B的数据库。包括一个系统，本身业务复杂度也没这么复杂的时候，也没必要把业务拆得太细。当你把一个服务拆分太多后，各个微服务之间做集成，做交付的工作量就会非常巨大。
第三个点就是谈微服务就会谈到微服务治理。个人希望微服务本身的设计开发和后续的微服务治理本身是能够分开的。但是我们当前主流的类似SpringCloud微服务架构里面有服务注册中心、微服务网关、有限流熔断和链路监控。但是我们可以发现一个重要的问题，就是很多设计开发的能力和后续的治理能力是耦合在一起的。简单来讲就是一个开发，在开发微服务的时候，实际上会增加很多治理的属性在开发时候的配置文件里面，这本身并不是一个合理思路。也正是这个原因，随着云与生DevOps的发展，微服务的治理逐渐为演变成基于Service Mesh的服务网格这种模式。
服务网格的微服务治理模式下面，我们通过在Devops持续集成部署的时候，自动下发便车代理，做到对微服务开发的时候没有任何的侵入性。这是我们希望去做的一个微服务治理模式。
最后是点是在微服务架构里面我们习惯与SOA进行比较，认为SOA或者ESB是一个中心化的架构模式，对微服务时完全去中心化，实际上这个理解并不是特别的准确。在SOA架构里面，我们可以看到我们会用到微服务网关。或者是用到API网关。实际上API网关也是一个中心化的东西，所有流量都会经过API网关，这个跟SOA的ESB总线道理是一样的，只是API网关更轻量。为什么又要谈到微服务架构是去中心化的架构呢。因为在微服务架构里面实际有两类流量，一类是整个微服务要对外暴露的南北流量，还有微服务之间交互的东西流量，在微服务架构里面，希望做到东西流量的交互是去中心化的。不管是基于Service Mesh还是基于服务注册发现中心都可以看到东西流量的交互一定可以实现去中心化。但是整个微服务应用需要对外暴露接口的时候还是需要通过API网关，对于南北流量还是中心化的架构，跟老的SOA和ESB总线是一样的。
网友评论