关于微服务的优缺点
0
悬赏园豆：5
[已解决问题]
解决于 2020-07-01 11:48
我一直不太明白微服务到底有什么样的好处，希望大家说明一下自己的看法（以下个人看法是以简单三层为例）
1.有人说他内聚且代码容易理解，我觉得在前后台分离的前提下，这样的说法应该不存在
2.微服务低耦合，在使用接口化开发的模式下（尤其是存在多种服务商的工具层，如：数据层，缓存工具类等），在这种情况下也不是特别的明显
3.小团队级不同语言开发，个人觉得这完全不是优势，以现如今的web趋势来说基本都是采用webapi形式进行交互，同样的功能人力资源成本几乎一样，你选择多语言开发人员风险更大
4.有利于自动化测试，我不是专业的测试不做评价
5.每个服务可以有自己的存储能力，这个我觉得传统情况应该也可以扩展，这个我也不认为是什么优点，最多可以说比较安全因为每个团队只能操作自己的那一部分，不会出现程序员不开心完全删库那种情况，但是也可以使用数据库不同用户分权限来实现
6.部署成本低无需全量替换，这个我认为现如今都使用svn、git等版本管理工具，问题应该不是很大，不过考虑到大型平台可以理解
7.可以频繁发布版本，这点我并不认可，客户往往在技术层面非常薄弱的，他们只会看表象，分散开发并不能体现出优势来，以敏捷开发为基础，根本体现不出分散开发的优势
8.分布式事务优势，我就想问一下，难道传统单应用就不能分布式？
以上仅个人看法，我最近准备研究微服务，但是我想知道他的到底有什么样的优势，也可能是我的理解上有问题，希望大家发表一下各自的看法
最佳答案
0
不必强求微服务“全家桶”套餐，理解微服务的优势，也要警惕微服务造成的问题。
简单举个例子。我们有一个用户服务API，提供了用户注册、登录、信息查询修改等功能。
1.登录注册功能属于要求很稳定，需求也较少变更的业务，我们不想因为更新一个信息查询的接口的操作不当造成这块业务的崩溃，所以我们把这块业务 剥离出来单独部署成一个服务。这里我们就已经开始入门微服务了，业务拆分，独立部署。
2.随着各种小服务的独立部署，服务认证授权、流量控制、监控怎么办，不可能每个服务都来一套吧，这时候ApiGateway应运而生。
3.因为大量的服务API，运维部署的压力就来了，这时候又要用到docker技术。。
4.因为大量的服务API，服务调用链问题要方案解决，分布式事务问题也要方案解决
慢慢的 微服务框架 就越来越大了。。其实我们最初想解决的问题只是希望 服务独立 互不耦合。
收获园豆：5
其他回答(3)
0
1、前后台分离与业务分离不同；
2、低耦合，你觉得什么样才算明显呢？
3、每一种语言都有适用场景，难道你让做大数据用C++？但是如果公司收购了一个使用其他语言的小公司，难道要马上来一次系统的重构，将语言统一？可以了解一下thrift；
5、你觉得淘宝的数据库表有多少？虽然可以给不同的团队的不同员工分别不同表的权限，但是每次要申请权限都要找集团DBA，注意不是部门DBA，也不是你们小组的领导，但是每个服务有存储能力，那么每个服务又有自己的数据库表，数据库表操作只需要服务负责人有权限，相对简单；这个例子不咋好
6、不是git和svn的问题，如果整个淘宝都是一个代码库，那么每当有一个改动，即使改动很微小，都要将整个代码库的代码进行构建打包发布，你觉得有必要吗？
7、淘宝如果每半年发布一次，那么今天发现的bug，比如订单模块有个小bug，要半年后修复？
8、传统单应用可以搞成分布式，但是需要解决分布式事务。
综上，你目前接触的系统规模不是很大的系统，业务的复杂程度还不太高，用户数量还很小，如果用户在千万或者亿级别，你就不会这么想了。
0
网上所谓的优势，几乎都有对应的劣势：
一般来讲，能单应用就用单应用，业务量大可以考虑做分布式集群。
更大规模的场景，单应用已经无法支撑业务，考虑微服务化。
为了微服务而微服务完全没有必要，在提出微服务概念以前，一个大系统本身分成很多小系统，这和现在的微服务并没有本质的区别。
更多的，我觉得现在很多企业是跟风，以及在虚拟机、云计算、大数据的风潮下，随之伴生了很多好用的微服务框架，可以大幅提高生产力。
总之，微服务有适合它的场景，但不是全能的。不过学习一下对工作还是很有用的。
0
相对比微服务 我们先说传统的单体应用架构
单体应用在公司初创时期是比较好的一种方案，要快速增加新功能或者部署发布都比较简单，但是随着时间的推移，危机就慢慢显露出来，任何一个bug都可能导致整个应用瘫痪，正所谓牵一发而动全身。
既然传统的单体应用架构不能满足业务的发展，那么架构的改变必然会提上日程，在系统不能支撑当前用户量后，我们将项目按照不同的业务来做拆分，分成多个子系统，系统之间通过Webservice或者Http接口来进行交互，这样做的好处是系统不再那么臃肿了。随着用户量越来越多，系统的压力也随之增长。可能其中某一个模块使用的频率比较高，这个时候需要对模块进行扩展，其实就是多部署几个节点。前面再加一个Nginx用于负载均衡，刚开始也还没什么大问题，当子系统越来越多的时候，每个子系统前面都要加一层负载均衡，对于运维人员来说工作量就增加了，因为要维护的更多了。
前面讲了这么多还是不能满足互联网公司快速发展的需求，比如高并发、高可用、高扩展，于是基于之前的架构又改进了一番，例如，引入了阿里巴巴开源的Dubbo框架，解决了服务之间的调用问题，服务调用方不再需要关注服务提供方的地址，只需要从注册中心获取服务提供方的地址即可。
再说下使用微服务的优势和劣势。
优势：服务独立部署、耦合低、服务能快速启动、可以动态按需扩容、代码易复用。
劣势：分布式部署调用复杂性高、独立数据库带来的分布式事务挑战、对测试、运维要求高。
