
课程咨询: 400-996-5531 / 投诉建议: 400-111-8989
认真做教育 专心促就业
微服务架构开发随着互联网的不断发展而被越来越多的程序员掌握并应用到不同的软件开发项目之中,而本文我们就通过案例分析来简单了解一下,微服务架构服务拆分需要考虑哪些问题。
做微服务开发的重要的一步,是服务拆分。按照微服务风格的要求,要考虑的是按业务拆分,这就要求架构师,先分析业务需求,做好业务边界,然后再按照业务模块对系统进行拆分。一般来说,拆分需要考虑以下几点。
独立性:拆分出来的服务,应该是独立的,它可以独立运行,支撑某一块业务,是一个独立的产品,应该具备高内聚和低耦合的特点,同时它会保留一些明确的接口,提供给三方进行服务调用。
明确服务粒度:服务是根据业务的需要进行划分的,但是有时候需要考虑粒度。例如,用户服务按照公司业务,需要十分精细化地划分为企业用户和个人用户,而企业用户十分复杂,这个时候就可以考虑将用户服务,拆分为企业用户服务和个人用户服务了。当然,如果两者区别不大,业务不多,也可以不进行拆分,这些都需要根据业务数据的大小、复杂度和边界(是否清晰)来决定。
团队分配:微服务的风格要求每一个服务是一个独立的产品,要有独立的团队进行开发、运维和部署。而实际上,这样成本会十分高。有时候,由于人员投入不足,一个团队维护多个业务微服务系统也是常见的,这时就需要考虑业务和团队的协作问题了,需要进行合理的分工和业务分配。
演进型:微服务的拆分不是一成不变的,它会随着时间的变化而变化。例如,刚开始,用户业务数据并不多,业务也相对单一,这个时候有一个用户服务就可以了。但是后续随着业务的深化,用户数据会急剧膨胀,在业务划分上也会更精细化,会将用户分为高级用户和普通用户管理,这时就可以考虑将原有的用户服务拆分为普通用户服务和高级用户服务两个服务了。所以在设计的时候,需要考虑未来可能的细化方向。
避免循环依赖和双向依赖:微服务应该避免循环依赖,一个业务不能同时由两个系统维护,必须有清晰的边界。例如,很多时候产品和财务是关联的,有时候财务需要按照产品维度出报表,这里需要明确的是,产品表只能在产品服务内维护,而财务需要产品的信息,需要有明确的接口和同步时间界限,以避免财务的内容去维护产品的内容,造成数据的混乱。
微服务的拆分规则并不是平等的,应该以业务拆分为一原则,进行划分,界定清楚边界,提供少量的服务接口供外部调用,同时应该考虑实际的情况,如需求的细化程度、数据量、团队拥有的资源、未来的预期和硬件情况等,实施微服务。
【免责声明】本文系本网编辑部分转载,转载目的在于传递更多信息,并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题,请在30日内与管理员联系,我们会予以更改或删除相关文章,以保证您的权益!更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销,赚更多好礼。