前言
大家对微服务是怎么理解的?在大家心里微服务是什么样的?究竟什么是微服务?微服务的组织架构是怎么分层的?下面就给大家介绍一下。
1.什么是微服务
1)一组小的服务(大小没有特别的标准,只要同一团队的工程师理解服务的标识一致即可)
2)独立的进程(java的tomcat,nodejs等)
3)轻量级的通信(不是soap,是http协议)
4)基于业务能力(类似用户服务,商品服务等等)
5)独立部署(迭代速度快)
6)无集中式管理(无须统一技术栈,可以根据不同的服务或者团队进行灵活选择)
ps:微服务的先行者Netflix公司,开源了一些好的微服务框架,后续会有介绍。
2. 怎么权衡微服务的利于弊
利:强模块边界 。(模块化的演化过程:类–>组件/类库(sdk)–>服务(service),方式越来越灵活)
可独立部署。
技术多样性。
弊:分布式复杂性。
最终一致性。(各个服务的团队,数据也是分散式治理,会出现不一致的问题)
运维复杂性。
测试复杂性。
3. 企业在什么时候考虑引入微服务
从生产力和系统的复杂性这两个方面来看。公司一开始的时候,业务复杂性不高,这时候是验证商业模式的时候,业务简单,用单体服务反而生产力很高。随着公司的发展,业务复杂性慢慢提高,这时候就可以采用微服务来提升生产力了。至于这个转化的点,需要团队的架构师来进行各方面衡量,就个人经验而言,团队发展到百人以上,采用微服务就很有必要了。
有些架构师是具有微服务架构能力,所以设计系统时就直接设计成了微服务,而不是通过单服务慢慢演化发展成微服务。在这里我并不推荐这种做法,因为一开始对业务领域并不是很了解,并且业务模式还没有得到验证,这时候上微服务风险比较高,很有可能失败。所以建议大家在单服务的应用成熟时,并且对业务领域比较熟悉的时候,如果发现单服务无法适应业务发展时,再考虑微服务的设计和架构。
4.微服务的组织架构
如上图左边,传统的企业中,团队是按职能划分的。开发一个项目时,会从不同的职能团队找人进行开发,开发完成后,再各自回到自己的职能团队,这种模式实践证明,效率还是比较低的。
如上图右边,围绕每个业务线或产品,按服务划分团队。团队成员从架构到运维,形成一个完整的闭环。一直围绕在产品周围,进行不断的迭代。不会像传统的团队一样离开。这样开发效率会比较高。至于这种团队的规模,建议按照亚马逊的两个披萨原则,大概10人左右比较好。
5:怎么理解中台战略和微服务
中台战略的由来:马云2015年去欧洲的一家公司supersell参观,发现这个公司的创新能力非常强,团队的规模很小,但是开发效率很高。他们就是采用中台战略。马云感触很深,回国后就在集团内部推出了中台战略。