戳蓝字“CSDN云计算”关注我们哦！
微服务(Microservice Architecture)是近几年流行的一种架构思想,关于它的概念很难一言以蔽之。今天，就让我们来看看关于微服务更加有深度的问题吧。
1 Q：什么是微服务
A：1）一组小的服务（大小没有特别的标准，只要同一团队的工程师理解服务的标识一致即可）
2）独立的进程（java的tomcat，nodejs等）
3）轻量级的通信（不是soap，是http协议）
4）基于业务能力（类似用户服务，商品服务等等）
5）独立部署（迭代速度快）
6）无集中式管理（无须统一技术栈，可以根据不同的服务或者团队进行灵活选择）
ps：微服务的先行者Netflix公司，开源了一些好的微服务框架，后续会有介绍。
2 Q：怎么权衡微服务的利于弊
A：利：
强模块边界 。（模块化的演化过程：类-->组件/类库（sdk）-->服务(service)，方式越来越灵活）
可独立部署。
技术多样性。
弊：
分布式复杂性。
最终一致性。（各个服务的团队，数据也是分散式治理，会出现不一致的问题）
运维复杂性。
测试复杂性。
3Q：企业在什么时候考虑引入微服务
A：从生产力和系统的复杂性这两个方面来看。公司一开始的时候，业务复杂性不高，这时候是验证商业模式的时候，业务简单，用单体服务反而生产力很高。随着公司的发展，业务复杂性慢慢提高，这时候就可以采用微服务来提升生产力了。至于这个转化的点，需要团队的架构师来进行各方面衡量，就个人经验而言，团队发展到百人以上，采用微服务就很有必要了。
有些架构师是具有微服务架构能力，所以设计系统时就直接设计成了微服务，而不是通过单服务慢慢演化发展成微服务。在这里我并不推荐这种做法，因为一开始对业务领域并不是很了解，并且业务模式还没有得到验证，这时候上微服务风险比较高，很有可能失败。所以建议大家在单服务的应用成熟时，并且对业务领域比较熟悉的时候，如果发现单服务无法适应业务发展时，再考虑微服务的设计和架构。
4Q：微服务的组织架构
A：如下图左边，传统的企业中，团队是按职能划分的。开发一个项目时，会从不同的职能团队找人进行开发，开发完成后，再各自回到自己的职能团队，这种模式实践证明，效率还是比较低的。
如上图右边，围绕每个业务线或产品，按服务划分团队。团队成员从架构到运维，形成一个完整的闭环。一直围绕在产品周围，进行不断的迭代。不会像传统的团队一样离开。这样开发效率会比较高。至于这种团队的规模，建议按照亚马逊的两个披萨原则，大概10人左右比较好。
5Q：怎么理解中台战略和微服务
A：中台战略的由来：马云2015年去欧洲的一家公司supersell参观，发现这个公司的创新能力非常强，团队的规模很小，但是开发效率很高。他们就是采用中台战略。马云感触很深，回国后就在集团内部推出了中台战略。
简单的理解就是把传统的前后台体系中的后台进行了细分。阿里巴巴提出了大中台小前台的战略。就是强化业务和技术中台，把前端的应用变得更小更灵活。当中台越强大，能力就越强，越能更好的快速响应前台的业务需求。打个比喻，就是土壤越肥沃，越适合生长不同的生物，打造好的生态系统。
小伙伴们冲鸭，后台留言区等着你！
关于微服务，今天你学到了什么？还有哪些不懂的？除此还对哪些话题感兴趣？快来留言区打卡啦！留言方式：打开第XX天，答：……
同时欢迎大家搜集更多问题，投稿给我们！风里雨里留言区里等你~
重磅推荐↓ ↓ ↓
福利
扫描添加小编微信，备注“姓名+公司职位”，加入【云计算学习交流群】，和志同道合的朋友们共同打卡学习！
推荐阅读：
苹果宣布加入CNCF；华为要求美国运营商支付专利费；微软删除最大的公开人脸识别数据集
如何给老婆解释什么是微服务？
阿里巴巴杨群：高并发场景下Python的性能挑战
那些去德国的程序员后来怎么样了？
新技术“红”不过十年，半监督学习为什么是个例外？
独家对话V神! 质疑之下的以太坊路在何方?
真香，朕在看了！
