体系化认识微服务之二:如何实施微服务架构

Posted 技术视点

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了体系化认识微服务之二:如何实施微服务架构相关的知识,希望对你有一定的参考价值。

微服务作为一种架构风格,其主要特点是由很多小的服务组成,且每个服务都是可独立部署的,任何一个服务的升级部署都不会影响其他的服务。那么在企业中如何实施微服务这种架构呢?


按业务组织团队

康威法则:设计系统的组织,其产生的架构设计等价于族之间的沟通架构
在以往传统的软件架构中,所有的功能都是在一个单体系统中完成的,每个团队都可以在上面修改代码,开发测试部署也比较方面。但是随着业务的扩展和功能的不断迭代,单体系统越来越难以维护,故障率不断上升。

康威法则其实解决的是多团队并行开发的痛点,不同的业务有不同的团队维护,每个团队维护他们自己的服务,团队的边界会更加清晰,开发效率也会大幅提升。

按业务组织团队带来的结果是,每个需求的开发都是按产品进行交付的。也就是说需求的开发是跨团队的,这个团队会有各个职能部门的同学,比如产品经理、工程师、测试、DBA、运维等角色。

微服务产品交付流程如下:


第一阶段:产品经理会组织需求评审,明确这个产品要做什么,如果需求比较会先进行可能性评审
第二阶段:由于最终是以产品进行交付的,在实际开发中会明确一个项目负责人他会给出这个产品的技术文档,明确每个人要做什么以及怎么做的问题
第三阶段:给出方案后,不同职能部门的人员各自进行开发
第四阶段:开发完毕后,把产品(一般会有多个项目,每个项目不同的分支)交付给测试人员进行测试
第五阶段:测试完后,把产品交付给运维进行构建部署
第六阶段:运维构建部署后,开发人员发布上线
第七阶段:线上观察反馈,验证产品质量。如果有问题,产品重新提需求,进入一个闭环


服务拆分

单体应用要改成微服务架构的首要问题是,有哪些服务或者模块是要拆分出去,并且哪些服务要归属到各个业务团队;这些众多的服务要怎么拆分。


哪些服务要拆分
所有的服务按照业务维度可以分为两种:业务相关和业务无关的服务。
业务无关的服务包括存储基础服务、公共服务。存储基础服务又可以分为数据库、缓存。公共服务分为短信服务、邮件服务、地图服务等。
业务相关的包括领域服务、存储领域服务。这里存储服务包括业务无关的服务,比如赠增删改查,又包括特定条件查询服务等和业务相关的存储服务。

服务怎么拆分
将需要拆分的服务梳理后还有一个问题要解决,这些服务怎么拆分。我们按照从底层到上层的方法拆分不同的服务,从底层到上层分别为:数据层服务、业务服务。


数据层服务是与业务无关的服务,把底层访问数据的细节以服务的方式提供出去,例如我们拆分出了经纬度服务、地图服务业务、城市服务等底层数据服务。业务服务是核心服务,把数据层服务+业务逻辑组合起来构成业务服务,业务服务把底层访问数据层的服务屏蔽起来,调用方不用关心具体细节,例如我们把订单和商家分为两个业务服务,按照业务的领域可以分为更多的业务服务。

以上是关于体系化认识微服务之二:如何实施微服务架构的主要内容,如果未能解决你的问题,请参考以下文章

体系化认识微服务之二:如何实施微服务架构

体系化认识微服务之三:微服务总体技术架构

体系化认识微服务之三:微服务总体技术架构

微服务架构学习与思考(04):微服务技术体系

体系化认识微服务之一:什么是微服务

体系化认识微服务之一:什么是微服务