【话题讨论】理解微服务架构，实践云原生应用！

post200

微服务与容器结合会发展出新趋势--Cloud Native，什么是Cloud Native？
CloudNative 最大的思维转变当属 Stateless Infrastructure（无状态基础设施）。这样可以大幅度保障应用的可用性和水平扩展能力，当传统的计算资源和存储资源已经通过云计算技术达到了海量。应用的瓶颈就来自于应用架构和基础设施结构。如果还在思考基础设施的状态如何监控和保存，就又进入了老的思维模式，只不过换了新的工具而已。

aloki

1.微服务的定义？微服务需要“微”到什么程度？
微服务 (Microservices) 是一种软件架构风格，它是以专注于单一责任与功能的小型功能区块 (Small Building Blocks) 为基础，利用模块化的方式组合出复杂的大型应用程序，各功能区块使用与语言无关 (Language-Independent/Language agnostic) 的 API 集相互通信。
尽管“微服务”早已成为一种极具人气的架构类型，但这一名称却并不能准确反映服务的实际规模——换言之，“微”服务并不一定微，具体规模可谓多种多样。规模较小的团队则由六人组成，负责支持六项服务。

2.微服务的重大优势是什么？它是未来吗？
·提升开发交流，每个服务足够内聚，足够小，代码容易理解；
·服务独立测试、部署、升级、发布；
·按需定制的DFX，资源利用率，每个服务可以各自进行x扩展和z扩展，而且，每个服务可以根据自己的需要部署到合适的硬件服务器上；
·每个服务按需要选择HA的模式，选择接受服务的实例个数；
·容易扩大开发团队，可以针对每个服务（service）组件开发团队；
·提高容错性（fault isolation），一个服务的内存泄露并不会让整个系统瘫痪；
·新技术的应用，系统不会被长期限制在某个技术栈上；

微服务架构有很多吸引人的地方，但在拥抱微服务之前，也需要认清它所带来的挑战。

3.微服务在实践过程中最大的难点是什么？
·开发人员要处理分布式系统的复杂性；
·服务之间的分布式通信问题；
·服务的注册与发现问题；
·服务之间的分布式事务问题；
·数据隔离再来的报表处理问题；
·服务之间的分布式一致性问题；
·服务管理的复杂性，服务的编排；
·不同服务实例的管理。

4.微服务、容器技术两者的关系？两者结合带来什么新趋势？
虽然使用一般的服务器虚拟化技术就能应用于微服务的管理，但容器技术 (Container Technology) 如 Docker 会更加地适合发展微服务的运算资源管理技术。Docker
作为一种开源的应用容器引擎，帮助开发者将他们的应用以及依赖打包到一个可移植的容器中，便于应用的部署和扩展。而随之产生的微容器概念和微服务正好相辅相成，通过Docker 封装的应用可以轻松运行在以扩容能力见长的云计算平台上。数人云作为专业的数据中心管理系统，提供了基于 Mesos 和Docker 技术的企业级容器云生产环境，通过一键部署、横向扩展、持续集成等特性，助力微服务架构在企业应用环境的实践。

5.怎么处理微服务与外部相连，以及获取数据？
单个微服务在上线的时候，会向服务探索中心（如：Consul）注册自己的 IP 位置、服务内容，如此一来就不需要向每个微服务表明自己的 IP 位置，也就不用替每个微服务单独设置。当服务需要调用另一个服务的时候，会去询问服务探索中心该服务的 IP 位置为何，得到位置后即可直接向目标服务调用。

这么做的用意是可以统一集中所有服务的位置，就不会分散于每个微服务中，且服务探索中心可以每隔一段时间就向微服务进行健康检查（如透过：TCP 调用、HTTP 调用、Ping），倘若该服务在时间内没有回应，则将其从服务中心移除，避免其他微服务对一个无回应的服务进行调用。

laputa73

这个话题比较热门，
1.微服务的定义？微服务需要“微”到什么程度？
这个问题其实是微服务最核心的问题。
微服务其实并没有明确的定义，相对于单体应用，微服务有明显的差异。
但是相对于分布式的多服务体系，微服务的差异体现在哪里？
传统的SOA同样有服务注册、服务网关、服务路由。
微服务虽然可以脱离网关，只通过注册中心寻址，p2p调用，但是最佳的推荐应用方式仍然是通过网关。
所以，微服务更多是一个理念，而不是一个明确的概念。
微服务是不是越微越好？
答案我认为是否定的。
一个上百个api的系统，通过上百个服务来实现，会给运维来来无穷无尽的烦恼。
相反，类似的功能，聚合到一个服务中集中实现，效率更高。总体分为10来个服务可能就足够，
从单体到分布式集群是一个质的变化，但是从分布式到微服务，只是一个量的调整。

2.微服务的重大优势是什么？它是未来吗？
微服务最大的优势是统一了分布式RPC接口，让进程间通信和服务通信成为了统一模式，
只要分布式调用的需求存在，微服务的思想就在。
相对于传统的单体系统，微服务主要的革命是去掉了session，强制api无状态.

3.微服务在实践过程中最大的难点是什么？
粒度拆分的决策。
服务之间数据一致性问题。
运维问题。
多语言问题。
还有一个内外划分的问题，传统的系统功能明确，内部系统走rpc,外部系统通过soa相互通信。现在都统一成微服务了。
谁是内，谁是外？系统边界在哪？服务中心需要建一套，还是多套？

4.微服务、容器技术两者的关系？两者结合带来什么新趋势？
没有容器(docker)，也会有微服务。各种语言都有自己的web/rest app容器。
例如java的spring boot, python的flask.
但是有了docker容器，微服务的隔离更彻底，部署更清晰。
而且，依托k8s的容器调度，可以实现更高层次的微服务治理。

5.怎么处理微服务与外部相连，以及获取数据？
微服务的数据同步是个很复杂的问题。
理论上微服务之间只存在api调用. 但是每个微服务自己搞一个数据库是不现实的。
所以系统中需要有一部分服务，单独处理数据。成为数据服务。
然后通过这些服务，暴露数据操作接口。
对于这些数据服务，可以直接操作数据库，本质上和传统的服务/DAO这些没有太大差别。

微服务区分内外，和外部服务交互一定要过网关。
如果从外部获取数据，量小的走api,量大的可能走专用通道，例如文件，队列。

6.微服务与容器结合会发展出新趋势--Cloud Native，什么是Cloud Native？（可选答）
云原生的概念是相对于直接把老系统迁移到容器、虚机部署而言的。
实际上，只要用上了docker+微服务这一套体系。支持了集群扩缩容，自然就是云原生了。

多说一句，目前的的微服务架构，spring cloud还是主流
但是和云原生结合，service mesh(istio)才是更纯粹的微服务架构。

oswald

请问各位大佬，什么时候应该使用微服务？

nt1979

哪些应用可以从微服务收益？

mysdirma

回复 16# nt1979

• 记录型系统(System of Record)将从微服务方法中获益最多。例如可将大型应用按相对独立的业务功能分解成若干个微服务实现。

• 交互型系统(System of Engagement)也将受益于微服务方法，例如渠道应用可以应用“后端服务前端”的模式实现。

• 分析型系统(System of Insight)则可能对微服务受益不多。其他架构模式如管道及过滤模式可能更适用于分析型系统。

  
  

renxiao2003

1.微服务的定义？微服务需要“微”到什么程度？
将单一应用划分为一组小的服务，服务之间互相协调、配合，为用户提供最终价值的架构体系。而每个服务运行在独立的进程中，服务之间采用轻量级通信（通常是基于HTTP协议的Rest API），并且每个服务都承载着独立的业务单元责任，能够被独立的部署和发布。
微服务不需要像普通服务那样成为一种独立的功能或者独立的资源。定义中称，微服务是需要与业务能力相匹配，这种说法完全正确。不幸的是，仍然意味着，如果能力模型粒度的设计是错误的，那么，我们就必须付出很多代价。如果你阅读了Fowler的整篇文章，你会发现，其中的指导建议是非常实用的。在决定将所有组件组合到一起时，开发人员需要非常确信这些组件都会有所改变，并且规模也会发生变化。服务粒度越粗，就越难以符合规定原则。服务粒度越细，就越能够灵活地降低变化和负载所带来的影响。然而，利弊之间的权衡过程是非常复杂的，我们要在配置和资金模型的基础上考虑到基础设施的成本问题。
微服务到底应该微到什么程度，根据个人观点，不能太微，也不能不微。太微了容易造成资源的浪费，比如一个计算器功能，我们把加减乘除都做成微服务（即加是微服务，减也是）那么不管是使用者还是提供者都很繁琐，而且容易造成资源浪费，毕竟就算是用容器，容器本身也是需要一个运行环境的；如果不微，把所有功能都糅合到一起，那么哪天更新一个功能可能就要停止所有的服务。造成所有服务中断。
2.微服务的重大优势是什么？它是未来吗？
优势：首先，通过分解巨大单体式应用为多个服务方法解决了复杂性问题。第二，这种架构使得每个服务都可以有专门开发团队来开发。第三，微服务架构模式是每个微服务独立的部署。最后，微服务架构模式使得每个服务独立扩展。
将一个复杂的业务分解成若干小的业务，每个业务拆分成一个服务，服务的边界明确，将复杂的问题简单化。由于微服务系统是分布式系统 ，服务与服务之间没有任何的祸合 。服务与服务之问通过 HTTP 网络通信协议来通信，单个微服务内部高度祸合，服务与服务之间完全独立，无调合。如果是一个单体的应用，由于业务的复杂性、代码的祸合性，以及可能存在的历史问题。微服务的每个服务单元都是独立部署的 ，即独立运行在某个进程里。微服务的修改和部署对其他服务没有影响。微服务在 CAP 理论中采用的是 AP 架构，即 具有高可用和分区容错 的特点 。
微服务（架构）应该是未来软件（架构）的趋势。
3.微服务在实践过程中最大的难点是什么？
『微服务』强调了服务大小，实际上，有一些开发者鼓吹建立稍微大一些的，10-100 LOC服务组。
微服务应用是分布式系统，由此会带来固有的复杂性。开发者需要在RPC或者消息传递之间选择并完成进程间通讯机制。更甚于，他们必须写代码来处理消息传递中速度过慢或者不可用等局部失效问题。当然这并不是什么难事，但相对于单体式应用中通过语言层级的方法或者进程调用，微服务下这种技术显得更复杂一些。
另外一个关于微服务的挑战来自于分区的数据库架构。商业交易中同时给多个业务分主体更新消息很普遍。这种交易对于单体式应用来说很容易，因为只有一个数据库。在微服务架构应用中，需要更新不同服务所使用的不同的数据库。使用分布式交易并不一定是好的选择，不仅仅是因为CAP理论，还因为今天高扩展性的NoSQL数据库和消息传递中间件并不支持这一需求。最终你不得不使用一个最终一致性的方法，从而对开发者提出了更高的要求和挑战。

测试一个基于微服务架构的应用也是很复杂的任务。比如，采用流行的Spring Boot架构，对一个单体式web应用，测试它的REST API，是很容易的事情。反过来，同样的服务测试需要启动和它有关的所有服务（至少需要这些服务的stubs）。再重申一次，不能低估了采用微服务架构带来的复杂性。

另外一个挑战在于，微服务架构模式应用的改变将会波及多个服务。比如，假设你在完成一个案例，需要修改服务A、B、C，而A依赖B，B依赖C。在单体式应用中，你只需要改变相关模块，整合变化，部署就好了。对比之下，微服务架构模式就需要考虑相关改变对不同服务的影响。比如，你需要更新服务C，然后是B，最后才是A，幸运的是，许多改变一般只影响一个服务，而需要协调多服务的改变很少。

部署一个微服务应用也很复杂，一个分布式应用只需要简单在复杂均衡器后面部署各自的服务器就好了。每个应用实例是需要配置诸如数据库和消息中间件等基础服务。
4.微服务、容器技术两者的关系？两者结合带来什么新趋势？
另外一个关于微服务的挑战来自于分区的数据库架构。商业交易中同时给多个业务分主体更新消息很普遍。这种交易对于单体式应用来说很容易，因为只有一个数据库。在微服务架构应用中，需要更新不同服务所使用的不同的数据库。使用分布式交易并不一定是好的选择，不仅仅是因为CAP理论，还因为今天高扩展性的NoSQL数据库和消息传递中间件并不支持这一需求。最终你不得不使用一个最终一致性的方法，从而对开发者提出了更高的要求和挑战。

测试一个基于微服务架构的应用也是很复杂的任务。比如，采用流行的Spring Boot架构，对一个单体式web应用，测试它的REST API，是很容易的事情。反过来，同样的服务测试需要启动和它有关的所有服务（至少需要这些服务的stubs）。再重申一次，不能低估了采用微服务架构带来的复杂性。

另外一个挑战在于，微服务架构模式应用的改变将会波及多个服务。比如，假设你在完成一个案例，需要修改服务A、B、C，而A依赖B，B依赖C。在单体式应用中，你只需要改变相关模块，整合变化，部署就好了。对比之下，微服务架构模式就需要考虑相关改变对不同服务的影响。比如，你需要更新服务C，然后是B，最后才是A，幸运的是，许多改变一般只影响一个服务，而需要协调多服务的改变很少。
部署一个微服务应用也很复杂，一个分布式应用只需要简单在复杂均衡器后面部署各自的服务器就好了。每个应用实例是需要配置诸如数据库和消息中间件等基础服务。
微服务与容器结合能够更好的发挥和充分的利用计算机的资源。
5.怎么处理微服务与外部相连，以及获取数据？
对外部有了依赖
微服务架构设计中有一条重要的原则叫严出宽进，严出意思就是说你提供给其他服务的东西要尽可能的进行严格的校验。宽进就是你调用别人的接口要宽容，兼容各种情况。比如说你需要考虑别人的节点down了/api超时/api不可用等等因素。

为了解决这个问题，我们必须要针对具体业务，分析依赖类型，是强依赖还是弱依赖，强依赖包装成自己的服务异常返回码/或者直接告诉前端调用不可用。弱依赖，catch所有异常，无论依赖方发生什么，不能影响我的接口返回。

此外，我依赖的服务某段时间内接口错误率很高，调用方还在不停的发送请求，那么就会一直得到错误的结果，这时候这些请求其实是无效的，所以这时候需要客户端熔断，不再去调用服务方，给服务方恢复的时间，等过段时间再去重试，发现服务方可用时，再去调用。

网络调用

网络调用是耗时的，所以我们需要利用池化技术，复用连接，比如在单体应用中我们需要与数据库连接，会利用到数据库连接池来提高数据操作效率。那么微服务调用也是这么个道理，我们与其他服务建议http/tcp连接，也需要建立连接池。另外一个服务可能会依赖多个微服务，不能因为和某个服务之间的连接出了问题，影响到与其他服务的连接，所以需要做连接池隔离。

服务间调用有可能失败，所以我们需要有重试机制，比如因为网络抖动引发的超时问题，我们可以通过重试提高API的可用性。
但是思考一下坏的情况，某段时间网络或者服务端真的有问题了。客户端超时时间设置的很大的话，客户端等待的时间就会很长，然后再加上重试机制，就会将客户端的连接占满，造成客户端相关API不可用。
6.微服务与容器结合会发展出新趋势--Cloud Native，什么是Cloud Native？（可选答）
Cloud Native翻译为云原生，是Matt Stine提出的一个概念，它是一个思想的集合，包括DevOps、持续交付（Continuous Delivery）、微服务（MicroServices）、敏捷基础设施（Agile Infrastructure）、康威定律（Conways Law）等，以及根据商业能力对公司进行重组。Cloud Native既包含技术（微服务，敏捷基础设施），也包含管理（DevOps，持续交付，康威定律，重组等）。Cloud Native也可以说是一系列Cloud技术、企业管理方法的集合。

incle

微服务通常由重写一个模块开始。要把整个巨石型的应用重写是有很大的风险的，也不一定必要。我们向微服务迁移的时候通常从耦合度最低的模块或对扩展性要求最高的模块开始，

把它们一个一个剥离出来用敏捷地重写，可以尝试最新的技术和语言和框架，然 后单独布署。 它通常不依赖其他服务。微服务中常用的API Gateway的模式主要目的也不是重用代码，

而是减少客户端和服务间的往来。API gateway模式不等同与Facade模式，我们可以使用如future之类的调用，甚至返回不完整数据。