架构设计笔记_15_关键模式_微服务

Posted 昌明说

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了架构设计笔记_15_关键模式_微服务相关的知识,希望对你有一定的参考价值。

2020年7月 杭州西湖


在高扩展问题那一篇说过,微服务是提供系统扩展性的一种手段,那SOA行不行,ESB呢?SOA是一种扩展方式,解决的主要问题是异构系统之间的数据传输问题,适用场景是传统的大型企业内部IT系统,为了不重复建设,适用ESB技术来保证各个异构系统之间,不同协议之间能够进行数据交换,从而达到节约重构系统所带来的成本的目的,SOA更加的是一种架构理念,是从整个企业IT系统角度出发的。而微服务强调的是微,粒度更细,一个子系统就可以进行微服务的划分,划分原则有可能基于业务,或者基于稳定性和非稳定性等,另外其场景更加的是互联网系统,迭代速度要求快,故障隔离要求高,并且要求能够快速交付和部署运维。


实现微服务后,并不是银弹,首先要关注这种架构能够解决的问题是否切合我们的实际需求,另外一个点要看实施微服务架构后的基础设施是否满足,比如,服务发现注册,以及服务容错监控等这些基础设施是否有了,接口通讯是RPC还是HTTP?接口数据格式确定是什么?API网关是否有选型?配置中心,自动化测试和部署这块是否具备?微服务带来的问题也是很明显的,问题难以追踪,链路长,因为系统分散,开发和依赖变得更加复杂,需要上面提到的一些基础实施的支撑。


Runnf这种互联网应用,其特征是完全符合微服务架构的,但是我们在实施的过程中,也是根据实际资源情况有限的进行的。


  • 服务的划分粒度


根据团队情况,规模较小,服务粒度不能太细,否则人手不够,核心业务包括用户,轨迹,小组,动态,社交,福利,非核心业务包括不定期举行的活动,合作厂家定制开发,商城,论坛等。基于是否核心业务的划分原则可以保证核心业务的稳定性,让有经验的工程师来负责,而周边子系统可以让一般的来负责即可,但是基于实际情况,将用户,小组,社交划分为一个服务,2个人来维护,而轨迹,动态和福利划分为一个服务,2个人来维护,活动,论坛由1个人维护,论坛单独一个人维护,定制化开发的工作集中力量处理即可。所以具体粒度根据实际情况进行划分。


  • 服务发现注册容错


基于新浪微博开源的Motan,提供了微服务的基础功能,即服务的发现注册监控等功能,以及接口选型等,Motan提供了基于zookeeper的服务注册发现机制,以及服务熔断集群等功能,同时Motan是基于RPC机制进行通讯的,这样完全屏蔽了不同JVM之间的调用细节,Motan基于spring的配置扩展机制,非常容易集成到现有系统的spring框架中,另外,Motan也提供了一定的服务治理功能,如负载均衡和熔断机制等。


这些都是微服务实施的基础条件,我们通过第三方开源实现就可以实现了,同时Runnf整体架构上,将后台管理功能也进行了独立部署,包括后台管理库也从核心库中进行了分离。


  • API网关


内部服务提供的都是基于业务逻辑的服务API,需要通过统一网关对外提供服务调用,并且保证服务调用的安全机制,流量控制,路由等,所以Runnf的API网关是自研的系统,可以实现外部系统的访问统一分配,包括APP,PC端,以及合作伙伴的访问等。所以网关本身的稳定性就非常重要了,否则会导致服务整体不可用,API网关本身部署也要保证高可用和高性能。


对于Runnf来说,基于以上3个方面的微服务改造完成后,就已经可以做到系统扩展性的要求和工程实施的隔离性要求,但是,基于团队资源,自动化部署和运维还不能及时跟上,但是这部分前期可以用人工方式解决,不是核心问题。所以Runnf也是有限的一种微服务的实施,如果按照Spring Cloud的整体架构,还有很多工作需要去完成,合适的就是最好的,没有最好只有更好!