【好书推荐】微服务与单一服务架构的拼杀，如何选？

王楠w_n

话题背景：

微服务在过去几年成为一个非常受欢迎的话题。

“微服务狂热”就像这样：

Netflix在devops上非常棒。 Netfix做微服务。 所以：如果我做微服务，我也就非常擅长devops了。

很多情况下，团队已经付出了巨大的努力来选用微服务模式，却在选用之前并没有清楚应用于当前具体问题的成本和收益。

本篇话题的目的在于详细描述微服务是什么，为什么这种模式非常吸引人，还有一些目前遇到的关键挑战等问题。

讨论问题：

1. 如何理解微服务，简要说明您所理解的微服务是什么？

2. 与传统单一服务架构相比，在实战环境下，各自的优劣都有哪些？

3. 如果您考虑部署微服务，在业务部署过程中会遇到哪些关键挑战？

活动时间：2018年7月4日-8月4日

活动奖励：

活动结束后，我们将会选取5个讨论精彩的同学，送技术图书《Spring Cloud 微服务架构开发实战（全新升级版）》一本。

出版社： 北京大学出版社
ISBN：9787301294567
版次：1
商品编码：12382428
包装：平装
开本：16开
出版时间：2018-06-01

购书链接：https://item.jd.com/12382428.html

内容简介：本书与其他书籍不同，特色是真正从实战角度出发，运用 Spring Cloud 技术来构建一个完整的微服务架构的系统。本书全面介绍 Spring Cloud 的概念、产生的背景，以及围绕 Spring Cloud 在开发微服务架构系统过程中所面临的问题时应当考虑的设计原则和解决方案。特别是在设计微服务架构系统时所面临的系统分层、服务测试、服务拆分、服务通信、服务注册、服务发现、服务消费、集中配置、日志管理、容器部署、安全防护、自动扩展等方面，给出了作者自己独特的见解。本书不仅介绍了微服务架构系统的原理、基础理论，还以一个真实的天气预报系统实例为主线，集成市面上主流的新的实现技术框架，手把手地教读者如何来应用这些技术，创建一个完整的微服务架构系统。这样读者可以理论联系实践，从而让 Spring Cloud 真正地落地。

样章试读： spring cloud微服务架构开发实战-试读.pdf (2.66 MB, 下载次数: 122)

2018-07-04 16:13 上传

点击文件名下载附件

c3po

我觉得吧，当微服务模块数量大于等于开发人数（甚至持平）的时候，就知道不是马爸爸就玩不起微服务了。

王楠w_n

回复 11# laputa73

存储这块，还有待提高，不知道有哪位大神可以帮忙回答下

王楠w_n

回复 2# infoback

学习到了

laputa73

1. 如何理解微服务，简要说明您所理解的微服务是什么？
微服务本质上就是SOA的自然演进,就是将rpc服务化,进而在部署上可以利用成熟的web技术,实现自动化.
其核心是接口服务化,部署容器化.
微服务的一个特点是随之而来的服务治理的问题,原本开发的工作相当于转移到运维了.
这就和devops搭上了.
微服务本身也可以用rpc接口,但是现有的rpc跨语言能力都不太强,用得多的还是http.
不过rest的效率有瓶颈,高性能的场景还需要抉择.

2. 与传统单一服务架构相比，在实战环境下，各自的优劣都有哪些？
如果是小规模集群, 尤其是双机集群,传统的单一架构+LB/HA的效率更高.因为避免了无效的rpc.
如果是上规模的云环境, 微服务架构成了很好的选择.
这2者之间, 可以用业务拆分+单一服务架构, 也可以用微服务架构.前者重效率,后者重弹性.


3. 如果您考虑部署微服务，在业务部署过程中会遇到哪些关键挑战？
首先是历史系统的迁移,要做好接口服务化和体系重构.这个是大头的工作量.
其次是微服务框架的选型.现在spring cloud比较流行.不过对于非java语言,还是有些不通畅.
在来是部署, 微服务配容器,k8s/rancher也不轻省.
还有就是存储, 微服务体系里面最闹心的就是存储.貌似没有特别好的方案.多数还是拿rdbms凑合事.

fire_cpp

1. 如何理解微服务，简要说明您所理解的微服务是什么？
万变不离其宗，都是向着模块化、标准化、高内聚低耦合的工程优化方向前进。人类各工程史无不如此发展。这东西没有具体的定义，你可以将系统做成几个独立的程序，互相之间通过REST API通讯，你能说不是微服务？但如果没有服务注册、发现、降级、断路、自动测试和部署等的配合，你可能有点不好意思说这是微服务“架构”。但它本质上就是一个微服务构成的系统，只要你做了解偶与业务边界的划分。

2. 与传统单一服务架构相比，在实战环境下，各自的优劣都有哪些？
可能没有做过的人并不能充分了解这些优劣。举两个我自己的例子：

一个是用Django开发的Web，所有的功能全在一个Django工程中完成。各功能间没有任务通讯开销，测试也非常顺畅，开发速度还是很快的，也不会出现各子系统间需要通过约定来约束接口和数据结构的情况，一个全局定义所有模块全部生效。但如果想改一个功能，必须将一个服务全部停掉才能更新。

另一个是微服务架构而成的系统，不同部分分别用了Django/Go/C++，互相之间除了通过REST接口通讯，部分还选择通过消息队列进行通讯。做单个服务的时候，是挺顺畅的，理解起来也没有阻碍，出了问题不用调试我都知道可能是哪出了问题。只是你做到D服务的时候，可能会把A、B、C服务的实现给忘了，互相之间只有约定好的接口，不看文档做根本不放心。而且，有些测试比单体服务困难，不是说构建测试困难，而是各服务之间的关系有时难以处理，有时端到端测试几乎是不可能的。你说这到底是降低是软件质量还是提高了软质量？很难说。但带来的好处也很明显，我可以单独部署、单独完成，选择合适的技术栈，横向扩展也非常方便。测试大多数时候还是比单体服务要方便的。

3. 如果您考虑部署微服务，在业务部署过程中会遇到哪些关键挑战？
最麻烦的，我觉得是测试。两三个关系不复杂的服务还好办，如果七八个服务，几十个接口，各种异步、并发，关系错综复杂，有些自动化测试根本没办法进行，或者成本极高。如果自动化测试没法进行，devops就谈不上。

另外的难点，就是服务粒度的划分，这是没有标准的，全看需求、凭经验。总地来说，前期粒度大一些，后期可以慢慢改小，但哪些可以合并到一起、哪些必须在前期就要分开，很考经验。

最后的难点，就是围绕微服务架构上的那一套了，比如服务注册、发现、降级、自动化测试和部署等等，真的全套做下来成本不低的，多数小团队没有精力去实施的。

Fl_wolf

1. 如何理解微服务，简要说明您所理解的微服务是什么？

服务架构风格是一种将单个应用程序作为一套小型服务开发的方法，每种应用程序都在自己的进程中运行，并与轻量级机制（通常是HTTP资源API）进行通信。 这些服务是围绕业务功能构建的，可以通过全自动部署机制独立部署。 这些服务的集中管理最少，可以用不同的编程语言编写，并使用不同的数据存储技术。

2. 与传统单一服务架构相比，在实战环境下，各自的优劣都有哪些？

解耦：对于我们底层程序员而言，看得见的好处就是解耦。我要实现一个功能，可能并不需要很深入的了解别人的代码，因为程序员嘛，可能都觉得别人的代码是个渣渣([哭笑不得])。我可以新作一个微服务，这个服务为其他功能提供服务，又不依赖于原来已有的功能，至于业务逻辑，可以一边上手一边熟悉 内聚，可以独立部署：意思就是我维护的这个微服务，可以独立部署，对其他服务不会是强依赖，不会存在因为其他服务不存在而造成我自己的服务不能启动或者不可用的问题。

分布式：微服务架构下不存在一个特别大的系统包含很多中心功能，这样也能提高容错性，一个服务的瘫痪并不会让整个系统瘫痪 权限验证：微服务是高度内聚的服务，我自己的这个服务，我可以定制任意合理规则，而这个规则又只适用于我自己的服务。相比于dubbo RPC调用，http微服务调用的权限验证可以更直接更严格更定制化，而rpc调用时的权限验证，我个人始终觉得不能做的很优雅 数据分开治理，自带分库属性：原来的大系统使用一个数据库，当数据很多流量很大时，就会涉及到分库分表。

而微服务下，每个服务是否使用数据库，数据库是和其他服务公用还是自建，都有很大灵活性，即我觉得微服务自带分库分表属性 系统不会被长期限制在某个技术栈上，在微服务的架构下，整个系统不会受限于java或者nodejs 或者go，而是大家协同不冲突，全部http协议，json格式 各个模块的单元测试容易自动化 等

3. 如果您考虑部署微服务，在业务部署过程中会遇到哪些关键挑战？

xdsnet

回复 3# aloki

理解和整理比较的很好，我觉得你其实不需要那本书啦，哈哈！

fenyun689

1. 如何理解微服务，简要说明您所理解的微服务是什么？

以一个一个小的服务组成一个大的系统。框架搭建成功后，开发人员只关心服务的开发。

2. 与传统单一服务架构相比，在实战环境下，各自的优劣都有哪些？

微服务容易扩展，对于大规模的系统来说维护省力。单一服务架构适用于小系统，简单，稳定，方便。

3. 如果您考虑部署微服务，在业务部署过程中会遇到哪些关键挑战？

微服务与单一服务架构的业务是不一样的。需要重新设计。

稳定性，新东西都需要一个阶段的稳定期。

wh7211

1. 如何理解微服务，简要说明您所理解的微服务是什么？

微服务是一种架构风格，一个大型的复杂软件由一个或多个微服务组成。系统中每个微服务都可以被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成任务。在所有情况下，每个任务代表这一个小的业务能力。

微服务的核心思想是一个完整的应用由多个小的、相互独立的微服务组成，这些微服务运行在自己的进程中，开发和发布都没有依赖。不同微服务通过一些轻量级交互机制来通信，服务可独立拓展伸缩，每个服务定义了明确的边界，不同的服务甚至可以采用不同的编程语言来实现，由独立团队维护。微服务的目的是为了根据业务有效拆分应用，实现敏捷开发和部署。



2. 与传统单一服务架构相比，在实战环境下，各自的优劣都有哪些？

传统单体架构和微服务架构的优劣对比如下：

微服务架构是由一系列职责单一的细粒度服务构成的分布式网状结构，服务之间通过轻量机制进行通信，一般以集群方式提供服务。

（1）微服务架构的优势

• 模块可独立提供服务，每个服务都比较简单，只关注于一个业务功能，边界清晰，易于维护
• 通过最佳及最合适的不同的编程语言与工具进行开发，易于引入新技术，能够做到有的放矢地解决针对性问题
• 每个微服务可由不同团队独立开发，互不影响，加快推出市场的速度
• 微服务商店模式，快速的组合和重构
• 模块间松耦合，不同SLA保障计划，可以提供更高的灵活性
• 微服务架构是持续交付（CD）的巨大推动力，允许在频繁发布不同服务的同时保持系统其它部分的可用性和稳定性
• 更好的可扩展性和鲁棒性
  

（2）传统单体架构的劣势

• 加载、编译耗时长
• 代码管理复杂
• 横向扩展难
• 各模块之间的耦合程度高
• 随着新需求的增加，更新和修复大型整体式应用越来越困难
• 应用功能的快速上线能力差
• 快速变化的需求受到整体式应用的限制
• 随着应用云化的日益普及，生于云端的应用具有与传统IT不同的技术基因和开发运维模式
  

3. 如果您考虑部署微服务，在业务部署过程中会遇到哪些关键挑战？

会遇到微服务给DevOps带来的下列挑战：

（1）服务使用不同的编程语言开发，因此要为每种语言准备编译环境，为每个服务的部署准备不同的库和框架，让服务的开发和部署变得非常复杂；
（2）大量的微服务模块，复杂的版本管理和BUG跟踪，间接导致项目管理成本增加；
（3）分布式架构特性，服务分布在多个主机集群上，很难持续跟踪指定服务究竟运行在哪台主机上，后续的系统维护不方便；
（4）一个服务一个虚拟机，随着微服务架构不停的横向扩展，主机数量将快速增长，最小规模的主机配置可能也会超过了很多微服务对资源的要求，从而造成了超量配置并浪费开销；
（5）运维开销及成本增加，一个整体式系统如果由20个微服务组成，可能需要40-60个进程；
（6）必须具有DevOps开发运维一体化技能，具有较强DevOps技能的人员比较稀缺；
（7）隐式接口与接口匹配问题，把系统分为多个协作组件后会产生新的接口，在实际环境中，微服务架构会有更高的发布风险；
（8）代码重复，某些底层功能需要被多个服务所用，为了避免将”同步耦合引入到系统中“，有时候需要向不同服务添加同样的代码，这就会导致代码重复；
（9）分布式系统的复杂性，作为一种分布式系统，微服务引入了复杂性和其他若干问题，例如网络延迟、容错性、消息序列化、不可靠的网络、异步机制、版本化、差异化的工作负载等，开发人员需要考虑以上的分布式系统问题；
（10）异步机制，微服务往往使用异步编程、消息与并行机制，如果应用存在跨微服务的事务性处理，其实现机制会变得复杂化；
（11）可测性的挑战，在动态环境下服务间的交互会产生非常微妙的行为，难以可视化及全面测试；
（12）部署复杂，一个微服务应用一般由大批服务构成，这就形成大量需要配置、部署、扩展和监控的部分。

容器可以轻松实现微服务化后的DevOps，具备“独立性，细粒度，快速创建和销毁以及完善的管理工具”等特点的Docker可以为微服务提供一个完美的运行环境，当然，支持微服务的容器管理平台也需要解决诸如“基础架构服务管理，生命周期管理和团队协作，配置管理和部署支持”等问题。

jieforest

1. 如何理解微服务，简要说明您所理解的微服务是什么？
微服务即Microservices，是一种软件架构模式和风格，以专注于单一责任和功能的小型功能块为基础，利用模组化的方式组合出复杂的大型应用程序，各功能块的使用与编程语言无关的API集相互通信。微服务架构运用于软件架构风格的其中一项概念是甘露运算（Dew Computing），意指由许多的“小露水”（即代表微服务的功能块）汇集而成的整体服务能力。微服务存在于一个更大的生态系统中。重要的是不要只考虑一个微服务。要确保微服务考虑如何连接到更大的系统中。
简而言之，微服务就是在业务逻辑上具备单一功能（或单项功能）的REST API服务。

2. 与传统单一服务架构相比，在实战环境下，各自的优劣都有哪些？
单体应用即Monolithic，单体应用架构即Monolithic Architecture。与微服务架构相比，

单体应用架构的优势：
1）易于开发（流行的IDE都适合）
2）易于测试（功能放于一起，部署于一个环境，测试方便）
3）易于部署（单体应用打包成一个WAR文件）
4）易于水平伸缩（通过负载均衡器，很容易增加或删除单体应用的节点）

单体应用架构的劣势：
1）维护成本的剧增
2）持续交付周期的剧增
3）新人培养周期长
4）技术选型成本高
5）可扩展性较差
6）构建全功能团队困难
7）随着业务规模的剧增，单体应用在架构上难以满足业务快速变化的需要
8）代码的可维护性、可扩展性、灵活性存在问题

3. 如果您考虑部署微服务，在业务部署过程中会遇到哪些关键挑战？
实施微服务架构，遇到的挑战会有很多，下面列举主要的挑战：
1）构建微服务架构有难度。微服务架构只是一种软件系统的架构风格，它不是国际标准，也没有硬性规则，很少有指导方针或文档可以帮助您了解如何使用微服务构建和部署软件。故要构建优秀的微服务架构，需要做大量的实践。
2）实施DevOps是一项挑战。微服务架构通常建立在云和虚拟化的基础之上，并且在很大程度上依赖于自动化来确保成功并避免故障。公司或组织应采用DevOps文化并拥有适当的基础架构以避免出错。
3）会打破现有的研发生态。应该知道，一旦打算开始微服务架构，切换回来就异常困难。必须在企业文化、工具和流程方面发生改变才能实现微服务。
4）开发微服务架构需要的技能比较高，部署、监控等都有一定的技术门槛。
5）微服务架构的日志管理也是一个挑战。
6）微服务架构的故障定位、故障隔离也是一个挑战。
6）对所有微服务实现版本管理和依赖管理也是一个挑战。