一文带你读懂微服务的技术架构体系，微服务不再难!

前言

大家对微服务是怎么理解的？在大家心里微服务是什么样的？究竟什么是微服务？微服务的组织架构是怎么分层的？下面就给大家介绍一下。

1.什么是微服务

1）一组小的服务（大小没有特别的标准，只要同一团队的工程师理解服务的标识一致即可）

2）独立的进程（java的tomcat，nodejs等）

3）轻量级的通信（不是soap，是http协议）

4）基于业务能力（类似用户服务，商品服务等等）

5）独立部署（迭代速度快）

6）无集中式管理（无须统一技术栈，可以根据不同的服务或者团队进行灵活选择）

ps：微服务的先行者Netflix公司，开源了一些好的微服务框架，后续会有介绍。

2. 怎么权衡微服务的利于弊

利：强模块边界 。（模块化的演化过程：类–>组件/类库（sdk）–>服务(service)，方式越来越灵活）

可独立部署。

技术多样性。

弊：分布式复杂性。

最终一致性。（各个服务的团队，数据也是分散式治理，会出现不一致的问题）

运维复杂性。

测试复杂性。

3. 企业在什么时候考虑引入微服务

从生产力和系统的复杂性这两个方面来看。公司一开始的时候，业务复杂性不高，这时候是验证商业模式的时候，业务简单，用单体服务反而生产力很高。随着公司的发展，业务复杂性慢慢提高，这时候就可以采用微服务来提升生产力了。至于这个转化的点，需要团队的架构师来进行各方面衡量，就个人经验而言，团队发展到百人以上，采用微服务就很有必要了。

有些架构师是具有微服务架构能力，所以设计系统时就直接设计成了微服务，而不是通过单服务慢慢演化发展成微服务。在这里我并不推荐这种做法，因为一开始对业务领域并不是很了解，并且业务模式还没有得到验证，这时候上微服务风险比较高，很有可能失败。所以建议大家在单服务的应用成熟时，并且对业务领域比较熟悉的时候，如果发现单服务无法适应业务发展时，再考虑微服务的设计和架构。

4.微服务的组织架构

如上图左边，传统的企业中，团队是按职能划分的。开发一个项目时，会从不同的职能团队找人进行开发，开发完成后，再各自回到自己的职能团队，这种模式实践证明，效率还是比较低的。

如上图右边，围绕每个业务线或产品，按服务划分团队。团队成员从架构到运维，形成一个完整的闭环。一直围绕在产品周围，进行不断的迭代。不会像传统的团队一样离开。这样开发效率会比较高。至于这种团队的规模，建议按照亚马逊的两个披萨原则，大概10人左右比较好。

5：怎么理解中台战略和微服务

中台战略的由来：马云2015年去欧洲的一家公司supersell参观，发现这个公司的创新能力非常强，团队的规模很小，但是开发效率很高。他们就是采用中台战略。马云感触很深，回国后就在集团内部推出了中台战略。