大规模微服务架构下的Service Mesh探索之路
今天给大家带来的内容叫做Service Mesh探索之路，但是在前面加了一个定语：大规模微服务架构下。之所以加上这个词，是因为我们这个体系是在蚂蚁金服这样一个大的架构下进行的，蚂蚁金服的体量大家可以想象，所以这个探索会带有一个非常隆重的色彩：对性能/规模/高可用等方面的思考。
今年6月初，在深圳的GIAC大会，我们同事披露了这个正在开发中的Service Mesh产品，我们现在暂时命名为Sofa Mesh。我们目前的产品都在Sofa品牌下，比如Sofa RPC，Sofa Boot等。今天我们详细介绍Sofa Mesh这个单独产品，上次大会只是简单披露，也就是给大家介绍说我们有这样一个产品，而我今天的内容是把这个产品详细展开。主要是三个内容：一是Sofa Mesh的技术选型，二是它的架构设计，以及在最后跟大家聊一下，蚂蚁金服在Sofa Mesh上的开源策略。
第一个是技术选型。
先上来一堆要求，刚才我们提到过的，因为是大规模，而蚂蚁金服的体量，大家可以想象到的。实际上在性能，稳定性上，我们的衡量标准，我们考虑的基石，都是以蚂蚁金服这样的一个规模来考虑的。
在这样一个规模下，我们会涉及到一些跟其他公司不太一样的地方，比如说：我们在性能的考量上会比较重一些。因为如果性能不高的话，可能没法支撑我们这样一个规模。在考虑性能的时候，就有另外一层考量：架构和性能之间的这个权衡和取舍是要非常谨慎的。性能要求不太高的情况下，架构可能的选择，和需要比较高性能的情况下，可能会有完全不一样的取舍。稳定性就不必说了。
部署方面的要求，首先是我们会用于多种场合：
主站是指我们蚂蚁金服内部，比如大家用的最多的支付宝。
金融云，可能有一部分和我们有联系的同学会有所了解，这个是我们推出的针对金融行业的云。
然后还有我们的外部客户
部署上会要求这三个场合都能使用。
部署环境也会有多种，刚才我们调查到，有部分同学相对比较前沿一些，现在就已经上k8s了。有部分同学还是停留在以前的虚拟机以及物理机这种状态，也有一部分自己上了容器，还有部分同学可能会使用不同的公有云和私有云。这几种不同的环境，我们都是需要满足的。
第三点可能要特殊一些，需要满足各种体系。刚才我们在调查的时候了解到，有部分同学是在做旧有系统改造，那在改造的时候就会遇到一个问题：除了Service Mesh之外，还需要跟原来的体系，比如说Sofa，或者社区主流框架如Dubbo，Spring Cloud，相互之间打通和过渡。怎么在技术转型期间平滑的让业务做变更，是我们在整个技术选型之前提出的实际要求。整个技术选型是在这样一个背景下进行的。
我们做技术选型的时候，有两大方向：
一个选择是在开源产品上做
我们先看右边的路线，起点是找一个开源产品，fork出来，做增强/扩展/定制，和内部集成。因为开源产品还在继续往前走，所以我们会持续做版本更新，也可以从社区拿到最新版本。相当于是从开源社区做获取，然后接下来做反馈，让我们的一些产品，我们做的东西反馈回去。
这条路线比较大的好处是从一开始就可以得到社区的支持，社区往前走的时候也跟着往前走。如果做的比较好，愿意让自己的产品反哺社区，那么社区也可以从中受益。
当然这里面有一个小问题，就是说可能我们自己这个产品路线和开源产品路线可能会有一些分歧，可能我们领先一步，也可能他们领先一步，或者一个事情可能有两个做法。这种情况下，如何让社区的接受我们的改动，会变成这条路线上比较头疼的一个问题。
这是两条路线上的第一条，选择以开源产品为起点。
另外一种思路全新打造
或者，如果手上已经有一套类库或者框架，可以在这个基础上做包装。
这条路线有一个好处，可控性比较强。因为整个体系是全新打造或者在原有体系上演进而来的，整套体系基本上都是自己的开发团队完全可控的。
这条路线会遇到一个问题，因为长期上看我们也是希望开源的，而开源就意味着不能将自己内部太多的定制化的东西直接做进去，所以在架构上需要考虑可扩展性，可以定制化。因为开源出去的应该是一个标准产品，这样的产品才可以得到社区和客户的认可。客户希望看到一个干净的东西，也需要做扩展，整个体系在设计上会有所不同。
两条路线的终点，从图上看，我们有两个目标：
1. 第一个目标是内部落地
前面提到的，我们需要在蚂蚁金服主站这样的一个巨大规模的场景下落地，这是蚂蚁金服自身的需求。
2. 第二个目标是技术输出
因为蚂蚁金服在公司策略上有科技输出的内容，不仅仅我们自己用，我们还需要给出去。
现在我们来看这个问题：目标在这里，然后有左右两条路线，我们该怎么选择？在做的技术选型的时候，这是一个非常大的分歧点，到底是从左边走，还是从右边走？
在公布结果之前，我们先来看一下有什么可选方案。
这是开源方案的选择，第一代的Service Mesh。
左边的Linkerd，这个基本上，目前看，大家都已经有点嫌弃了。因为它没有控制平面，用Scala写的，基于JVM，资源消耗比较大。它的可扩展性比较有限的，相对于Envoy的扩展性。然后它里面有个dtab，有接触到的同学就会有认识：dtab的语法，非常的不人性，很难理解，使用不太方便。另外它的功能是远远不够的，对于蚂蚁金服来说。另外这个产品本身的发展前景已经很暗淡了，所以这个选项就被淘汰了。
Envoy是非常不错的，做了一些令我们意外的事情：安心的去做好数据平面，没有往上面做很多的东西，而是创造性的提出了XDS API。整个设计是非常优秀的，性能和稳定性也表现得非常好，甚至看到业界有一个趋势，有一部分的公司开始把他们的nginx替换了，不再用nginx了，而是用envoy。也就是说，现在它的稳定性和性能达到和nginx一个级别，nginx大家应该都有听说过，envoy已经是这样一个工业成熟度。
我们当时选型时是比较头疼的，因为它是c++写的，c++14。和我们技术栈的差异会比较大，因为蚂蚁的技术栈是以Java为主，长期的话，我们可能部分转到Golang上去。在这种情况下，C++的技术栈，会让我们比较尴尬，也不是说我们找不到会c++的同学，而是说，长期上会和我们的方向不一致，我们要在Java和Golang的技术栈之外再加一个c++，这就比较难受。
然后我们内部会有大量扩展和定制化的需求。因为我们内部有我们自己的产品，我们自己的需求，我们的通讯方案，我们内部的追踪，监控，日志方案，所以工作量非常大。
总结说，我们觉得Envoy很好，但是我们不能简单用。但是它在数据平面上的表现我们是非常认可的，Envoy在这点做得非常好。
开源方案里面的第二代，istio是我们当时的第一选择，重点关注对象。Istio现在最大的问题在于它迟迟不能发布生产可用版本，大家如果对istio有了解的话，会知道istio刚刚发布了0.8版本，第一个长期支持版本，但是这个版本也不是生产可用。不出意外的话，按照目前的进度，istio应该会在7月份发布它的1.0版本，但是从我们目前的感受上看，1.0估计可能还是不能工业级的使用。所以需要等，而我们没法等，但是Istio的理念和方向我们非常认可。大家看一看，我们这个技术选型有多纠结。
右边的Conduit，现在Conduit的最大限制是它只支持k8s。而现在蚂蚁金服还没有普及k8s，我们现在还有很多系统是跑在非k8s上的。第二是它的数据平面是Rust编写的，这个语言更加小众了，在座的同学有没有人了解Rust这门语言？或者听过。（备注：现场大概十几个人举手）大概10%左右的同学听过。好，Rust语言排名大概在50名左右。这个语言本身还是蛮认可的，我还很喜欢这个语言，它的一些特性还是非常有道理，如果掌握好还是可以写出非常好的产品，但是它的入门台阶会比较高一点。这个地方比较讨厌的事情是说，因为这个语言本身比较小众，所
以基本上是没办法从社区借力的。这里可以举个例子，大家可以看一下Conduit的committer的人数，大概是25个左右，还包括像我这种只提交了几行代码的。Conduit从12月份开源到现在已经有半年时间，半年时间只有这么多的committer，其中真正有贡献大概9到10个人，基本上都是他自己的员工。也就说这个产品基本上没办法从社区借力，一个产品，如果大家一起来帮忙，其实很多的细节是可以完善的，但是Conduit就卡在Rust语言上。
然后还是同样有技术栈的问题，因为这个原因，基本上Conduit我们也没法用了。
我们再看一下国内的在Service Mesh领域，其他的一些比较前卫的同学，他们的选择会是什么？
首先是华为，华为自己做了一套Golang版本，名字叫做Mesher。这是由他们之前的一套类库演进而来。它走的路线是，先有类库和框架，然后加proxy，proxy打通了之后再慢慢的开始添加控制平面。这是一条非常非常标准的路线，我这边给一个词叫做老成持重，因为这条路是最安全的：每一步都是基于现有的产品，很快就可以到下一个里程碑，然后每个里程碑都可以解决一些实际问题，可以直接得到一些红利，这个方案是比较比较稳妥的。比如说第一步是把proxy做进去，有了这个切入口之后，就在第一时间获取跨语言的红利，还有技术栈下沉的好处。然后控制平面的创新，可以在这个基础上慢慢往前做。
在对接Istio这一条上，现在华为的策略，我们现在从公开途径了解到的是：部分对接istio，也就是有一部分的API 兼容Istio。但是细节上还不太清楚，因为它的开源还没出来，目前得到的消息是，会在7月份开源。
第二个是新浪微博的Motan Mesh，他们也是Golang的，但他不太一样，是全新实现。他们用Go语言重新写了一把，主要原因是因为它没有golang类库，Motan是基于Java的。
刚才看到的这两个产品，他们的思路大体上是相同的，差异在哪里？就是启动的时候是用已有的类库还是重新写？这两个选择之间最大的麻烦在于编程语言，华为原来有go的类库，所以继续用golang包装一下就好了。但是新浪的类库用的是Java，而sidecar选择的是go语言，所以只能重新做了。
我们再看腾讯，最近看到他们有类似的产品出来。我们看看他们的资料：在数据平台上继续选择Envoy，因为它比较成熟。腾讯的话大家比较熟悉，尤其是腾讯有非常深厚的c++背景，所以Envoy对他们来说，技术栈是非常OK 的。而且之前内部其他领域Envoy也是在用的，所以底层非常自然的选择了Envoy。然后控制平面上，据传是"挣扎了一下"。这个词是我抄过的，"他们挣扎了一下"，最后还是选了Istio。然后自己做定制和扩展，然后注意到他们也解耦了k8s。这也是其中一个关键的点：要不要绑定k8s？
这里还有UCloud的一个很有意思的做法，另辟蹊径啊。他的方案很有意思，是一个轻量级的实践：从Istio里面，将Envoy和Pilot单独剥离出来。就是说不用Istio整体，把Mixer和Auth的模块去掉，只要最重要的Envoy，然后把Pilot剥离出来。然后这个Pilot还是个定制版，把其他的adapter干掉了。Pilot主要是做服务发现，它底层用ETCD，做了一个ETCD的adapter，把其他的adapter从Pilot中去掉。做完这几个事情之后，整个体系就可以脱离k8s了，这是一个比较有意思的实践。
微服务系统设计方案 1.微服务本质 微服务架构从本质上说其实就是分布式架构，与其说是一种新架构，不如说是一种微服务架构风格。 简单来说，微服务架构风格是要开发一种由多个小服务组成的应用。每个服务运行于独立的进程，并且采用轻量级交互。多数情况下是一个HTTP的资源API。这些服务具备独立业务能力并可以通过自动化部署方式独立部署。这种风格使最小化集中管理，从而可以使用多种不同的编程语言和数据存储技术。 对于微服务架构系统，由于其服务粒度小，模块化清晰，因此首先要做的是对系统整体进行功能、服务规划，优先考虑如何在交付过程中，从工程实践出发，组织好代码结构、配置、测试、部署、运维、监控的整个过程，从而有效体现微服务的独立性与可部署性。 本文将从微服务系统的设计阶段、开发阶段、测试阶段、部署阶段进行综合阐述。 理解微服务架构和理念是核心。 2.系统环境
3.微服务架构的挑战 可靠性： 由于采用远程调用的方式，任何一个节点、网络出现问题，都将使得服务调用失败， 随着微服务数量的增多，潜在故障点也将增多。 也就是没有充分的保障机制，则单点故障会大量增加。 运维要求高： 系统监控、高可用性、自动化技术 分布式复杂性： 网络延迟、系统容错、分布式事务 部署依赖性强： 服务依赖、多版本问题 性能（服务间通讯成本高）： 无状态性、进程间调用、跨网络调用 数据一致性： 分布式事务管理需要跨越多个节点来保证数据的瞬时一致性，因此比起传统的单体架构的事务，成本要高得多。另外，在分布式系统中，通常会考虑通过数据的最终一致性来解决数据瞬时一致带来的系统不可用。 重复开发： 微服务理念崇尚每个微服务作为一个产品看待，有自己的团队开发，甚至可以有自己完全不同的技术、框架，那么与其他微服务团队的技术共享就产生了矛盾，重复开发的工作即产生了。
微服务架构的部署 本文从以下几个方面简要说明微服务架构项目的实践经验：架构选型、开发测试环境下的相关工具支持、人员分工及开发部署流程、相关设计及注意事项。最后，将根据实践经验讨论提高微服架构下的开发和运维效率的切实需求，进一步理清本项目所实现的容器服务管理平台的完善性需求。 本项目是一个企业级的容器服务管理平台，该平台的功能是基于容器实现的应用运行环境管理，以及应用开发阶段的持续集成和持续发布。简单的理解该平台的核心功能之一就是管理复杂应用的开发和运维环境，提高微服务架构下的开发和运维效率。项目的开发背景如下： 首先，该系统具有典型分布式应用系统特征： 该平台所运行的服务器配置不高，例如华为RH1288这类低配置服务器，允许硬件失败； 系统平台要求可根据实际用户数的规模进行伸缩部署，保证硬件资源的合理利用； 由于系统平台之上需要运行若干企业应用的开发和运行环境，可靠性是非常重要的，不允许单点失效。 其次，本系统功能复杂，从架构的角度需要将系统分成多个层次和若干个子系统。不同的层次、子系统根据具体情况需要采用不同的开发语言，由不同的开发小组完成。 第三，项目组成员由几个城市的异地团队协同开发，统一的开发环境和协同工具是必不可少的。 针对上述项目背景的考虑，本项目选择基于微服务架构进行项目开发。 开发、测试、部署使用到的工具集 “工欲善其事、必先利其器”，借助适合的流程和相关工具集，才能提高微服务架构下的应用开发效率。本项目利用DevOPs流程并选用一套相关工具集实现应用开发管理，提高开发、测试、部署的效率。 代码库：本项目使用分布式代码库Gitlab，它的功能不限于代码仓库，还包括reviews(代码审查), issue tracking(问题跟踪)、wiki等功能，是代码管理和异地团队沟通、协作工具的首选。 Docker镜像仓库、Docker：本项目用容器贯穿整个软件开发流程，以容器作为应用发布的载体，应用的开发环境和测试发版环境都运行在Docker容器中。对于复杂的开发和运维环境管理Docker具有先天的优势，目前国内外的互联网公司有大多数都已经将Docker应用到了他们的开发或者生产环境中了。
微服务架构落地最佳实践
难点1：“一步到位”的认知错觉 这些年微服务大红大紫，但是真正能够拿出来做为可实践的案例少之又少。大部分的微服务案例只能看到微服务架构的“演进结果”，但是看不到微服务架构的“演进过程”。这就像每个人看到一个架构的高峰，却没有看到攀登高峰的路径。 这就给很多架构师一个假象：微服务的架构是通过能力极高的架构师一步到位设计出来的。 这和很多团队自上而下的架构设计感受和相似。于是架构师们蜂拥而至，各种分析方法论层出不穷，讨论和分享络绎不绝。然而真正落地实施的却很少，使得微服务在网络上慢慢变成了一种“玄学”：微服务的实施在“理论研究”的阶段。 这违反了软件架构的最基本规律：架构是解决当前的需求和痛点演进的，而无法对没有出现的问题和痛点进行设计。因此，一步到位的整体的微服务架构设计完全没有必要。况且一个集中化的设计，很难体现微服务的轻量级优势。 我相信技术的发展一定是向不断降低成本的方向上发展的。如果新技术没有降低成本反而提升了成本，要么这个新技术有问题，要么一定是姿势不对，走错了路。 因此，准备实施微服务一定要有一个长期的思想准备。不过跨过了最初的门槛之后，剩下的工作可以被复制而且速度会越来越快。 难点2：“架构师精英主义”
很多产品对架构师的依赖很大，即“架构师精英主义”：认为产品架构只有这个组织的“技术精英”——架构师才可以完成，而团队其它成员只需要实现架构师的设计就可以。这是大型企业和大型系统的常见问题，这来源于长期的重量级企业级架构习惯。 而微服务则类似于一种“敏捷边际革命”：即由一个不超过2~8个人的小团队就可以完成的功能。而且这种规模的团队即使从整个产品团队移除也对整体产品的研发进度没有影响。因此，即使失败了不会带来太多的损失。不过，当第一个微服务改造成功，那么成功经验的复制带来的乘数效应却能带来很大的收益。 从架构改造投资的风险收益比来看，这是非常划算的。 因此，微服务团队完全没必要大张旗鼓，只需要两三个人就可以动工。但是，谁也没有微服务的实践经验啊，万一失败了怎么办？ 这就带来了下一个难点。 难点3：缺乏一个信任并鼓励创新的环境
微服务架构下的数据一致性
写在前面 随着微服务架构的推广，越来越多的公司采用微服务架构来构建自己的业务平台。就像前边的文章说的，微服务架构为业务开发带来了诸多好处的同时，例如单一职责、独立开发部署、功能复用和系统容错等等，也带来一些问题。 例如上手难度变大，运维变得更复杂，模块之间的依赖关系更复杂，数据一致性难以保证，等等。但是办法总是比问题多，本篇文章就来介绍一下我们是如何保障微服务架构的数据一致性的。 微服务架构的数据一致性问题 以电商平台为例，当用户下单并支付后，系统需要修改订单的状态并且增加用户积分。由于系统采用的是微服务架构，分离出了支付服务、订单服务和积分服务，每个服务都有独立数据库做数据存储。当用户支付成功后，无论是修改订单状态失败还是增加积分失败，都会造成数据的不一致。 为了解决例子中的数据一致性问题，一个最直接的办法就是考虑数据的强一致性。那么如何保证数据的强一致性呢？我们从关系型数据库的ACID 理论说起。 ACID 关系型数据库具有解决复杂事务场景的能力，关系型数据库的事务满足ACID 的特性。 ?Atomicity：原子性（要么都做，要么都不做） ?Consistency：一致性（数据库只有一个状态，不存在未确定状态）
?Isolation：隔离性（事务之间互不干扰） ?Durability：永久性（事务一旦提交，数据库记录永久不变） 具有ACID 特性的数据库支持数据的强一致性，保证了数据本身不会出现不一致。 然而微服务架构下，每个微服务都有自己的数据库，导致微服务架构的系统不能简单地满足ACID，我们就需要寻找微服务架构下的数据一致性解决方案。 微服务架构的系统本身是一种分布式系统，而本文讨论的问题其实也就是分布式事务之数据一致性的问题，我们来聊聊分布式系统的CAP 理论和BASE 理论。 CAP CAP 是指在一个分布式系统下，包含三个要素：Consistency（一致性）、Availability（可用性）、Partition tolerance（分区容错性），并且三者不可得兼。 ?C：Consistency，一致性，所有数据变动都是同步的。 ?A：Availability，可用性，即在可以接受的时间范围内正确地响应用户请求。 ?P：Partition tolerance，分区容错性，即某节点或网络分区故障时，系统仍能够提供满足一致性和可用性的服务。 关系型数据库单节点保证了数据强一致性（C）和可用性（A），但是却无法保证分区容错性（P）。 然而在分布式系统下，为了保证模块的分区容错性（P），只能在数据强一致性（C）和可用性（A）之间做平衡。具体表现为在一定时间内，可能模块之间数据是不一致的，但是通过自动或手动补偿后能够达到最终的一致。
关于举办“微服务架构设计与实战”高级培训班的通知 各有关单位： 作为一种新的设计和架构理念，微服务自2014年首次提出就引发了业界激烈的讨论。同时，Docker技术的迅速发展，也让微服务架构的实施变得更加容易。相比于传统的单体式应用而言，微服务这种小而化之、互相连接的设计理念不仅能让复杂应用的构建变得更加灵活，更能帮助创业企业在面对市场的高度不确定性时，快速推出新产品，低成本试错。那么，企业究竟该如何去设计、开发和部署微服务到自己的业务中去?如何做好服务发现和服务治理呢?中国软件产业培训网决定在举办“微服务架构设计与实战培训班”望各单位收到通知后组织相关人员参加。现将有关事宜通知如下： 一、培训时间及地点 2019年12月20日-12月23日北京 2020年01月10日-01月13日上海 二、主讲专家 程老师 CTO，微服务架构首席咨询师，国内较早倡导和实践微服务的先行者，多次受邀在大型技术会议主题分享“微服务架构”相关主题。超过10年以上的软件行业经验,从企业应用、互联网应用、服务化平台的架构设计、开发到自动化构建、持续集成、持续交付以及DevOps 的转型实施等有较丰富的实践经验。 范老师国内架构设计专家、多领域架构评审委员和技术架构组委员。信息技术领域具有坚实的学术背景和教学培训经验，多年研发和客户项目高级管理咨询能力，多年包括华为IPD 研发管理工作经历。善于用先进信息化技术架构和方法指导团队完成设计工作，具有雄厚的咨询能力。具有大型分布式团队的领导和管理经验。 三、培训特色 1. 理论与实践相结合、案例分析与行业应用穿插进行; 2. 专家精彩内容解析、学员专题讨论、分组研究;
微服务架构下的服务治理 一、经典微服务架构的特点以及问题 经典的微服务架构一般包含两个部分：API网关，一组微服务。API网关是唯一的请求入口，它还要负责负载均衡，路由编排，失效切换等工作。 经典的微服务架构图
关于经典微服务架构的文章很多，这里重点想分享一些我们实践经典微服务架构的一些问题： 1.“笨重”的API网关，由于它要负责各种核心功能，不能灵活扩展，比如负载均衡策略，也许每 个微服务类型需求都不一样，它很难灵活变更；随着对接的微服务越来越多，每个API网关也集成大量的功能。 2.API网关自身需要高可用保证，经典架构并不提供，随着后端接的微服务越来越多，也会造成很多 稳定性问题，它与微服务也需要两套运维办法，给运维带来额外成本。 3.服务注册与发现还是传统模式，不能级联代理，长连接也有限制，不能很好解决跨大网段，跨机 房，跨IDC中心的问题。
4.心跳机制比较单一，只是从连接层面考虑，没有上下文以及服务本身的监控，需要依赖第三方实 现。 5.失效切换机制单一，只能是联通性检查，对业务异常无感知，意味着不能根据业务异常切换。 6.没有自动高效的重试机制，需要考虑对API网关的改造。 7.几乎没有隔离机制，需要采用第三方技术解决。 8.微服务实现没有统一的技术栈支持，还处于原则规定阶段。 9.服务编排依靠人工，没有动态编排能力。 整体看来，经典微服务架构还不够“聪明和智能”，于是我们设计并着手研发新一代微服务计算平台，希望能够让其充分发挥微服务架构的优势和特性。 二、微服务计算平台的设计思想与抽象模型 1“微智能”的设计思想 “微智能”这个概念起源于智能家居，是目前智能硬件领域的一股创新思想。在提到“智能”这个词，通常是相对人而言，智能家居通过“智”的体现，更好的服务人的生活。于是，我们就思考是否系统或者服务也能体现“智”，如果与微服务相结合，让其更加“聪明”的工作？
微服务架构介绍
微服务是个说的挺长时间的概念，也是比较成熟的技术体系。像Spring Cloud，甚至提供了微服务所需要的全套框架，包括注册中心(Eureka)、配置中心(Config)、断路器(Hytrix)、API 网关(Zuul) 等组件。微服务体系庞杂，每个组件都能独自成章。 微服务与更早就起来的SOA 是什么关系? 个人觉得如果从概念上来说，微服务和SOA 都是一回事，强调把整个系统，按照多个服务的方式去组合及通信，而不是揉合在一起，但它们的内涵有很大的区别。 SOA 诞生在早期企业级的应用，其业务复杂、技术体系多样，SOA 强调的是各个服务之间，尤其是异构系统、遗留系统之间，建立起一套统一的协议和通信(SOAP)，以及寻址服务(UDDI)，它的侧重点在集成和兼容；与SOA 同期的另一种概念ESB(企业总线)，强调通过一根总线服务，把所有服务串联起来，由ESB 总线来屏蔽各种不同业务系统自身业务/ 语言/ 协议的特殊性，各服务以一种统一的方式，与总线相连，从而降低接入成本。 这两种概念，我感觉在国内没有太发展起来。一是国内的软件起步相对较晚，系统的整体复杂度——多厂商、多语言/ 技术栈、历史遗留系统的问题，还不算突出。而对于公司内部的产品系，又没有必要使用SOA、UDDI 来做复杂的集成。随着互联网的兴起和用户量的迅速爆发，企业自身的产品的微服务化的需求，快速发展起来，而与此同时SOA 这种以XML 为基础的SOAP 协议、以寻址为主要作用的UDDI，不能使用互联网产品的发展——SOAP 的XML 协议内容太多，造成性能明显下降；HTTP 协议的效率不如RPC；UDDI 只有寻址，缺少服务治理等功能。 在此种大背景下，以服务切分+ 服务注册+ 服务治理+ 限流降级+RPC+ 监控等为主要内涵的微服务，就快速发展起来的。国内的阿里巴巴走在前列，以Dubbo 为代表在国内互联网企业中得到广泛应用；后来Spring 官方发布Spring Cloud，揉合了一系列自研或其他企业捐赠的开源项目，发布微服务领域的Spring Cloud 产品。各自都有各自的优势和劣势，而
微服务架构设计
目录 一、微服务架构介绍 (3) 二、微服务出现和发展 (3) 三、传统开发模式和微服务的区别 (4) 四、微服务的具体特征 (7) 五、SOA和微服务的区别 (9) 六、怎么具体实践微服务 (11) 七、常见的设计模式和应用 (17) 八、优点和缺点 (23) 九、思考：意识的转变 (26)
一、微服务架构介绍 微服务架构（Microservice Architecture）是一种架构概念，旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦。你可以将其看作是在架构层次而非获取服务的 类上应用很多SOLID原则。微服务架构是个很有趣的概念，它的主要作用是将功能分解到离散的各个服务当中，从而降低系统的耦合性，并提供更加灵活的服务支持。 概念：把一个大型的单个应用程序和服务拆分为数个甚至数十个的支持微服务，它可扩展单个组件而不是整个的应用程序堆栈，从而满足服务等级协议。 定义：围绕业务领域组件来创建应用，这些应用可独立地进行开发、管理和迭代。在分散的组件中使用云架构和平台式部署、管理和服务功能，使产品交付变得更加简单。 本质：用一些功能比较明确、业务比较精练的服务去解决更大、更实际的问题。 二、微服务出现和发展 微服务（Microservice）这个概念是2012年出现的，作为加快Web和移动应用程序开发进程的一种方法，2014年开始受到各方的关注，而2015年，可以说是微服务的元年； 越来越多的论坛、社区、blog以及互联网行业巨头开始对微服务进行讨论、实践，可以说这样更近一步推动了微服务的发展和创新。而微服务的流行，Martin Fowler功不可没。 这老头是个奇人，特别擅长抽象归纳和制造概念。特别是微服务这种新生的名词，都有一个特点：一解释就懂，一问就不知，一讨论就打架。
大规模微服务架构下的Service Mesh探索之路 今天给大家带来的内容叫做Service Mesh探索之路，但是在前面加了一个定语：大规模微服务架构下。之所以加上这个词，是因为我们这个体系是在蚂蚁金服这样一个大的架构下进行的，蚂蚁金服的体量大家可以想象，所以这个探索会带有一个非常隆重的色彩：对性能/规模/高可用等方面的思考。
今年6月初，在深圳的GIAC大会，我们同事披露了这个正在开发中的Service Mesh产品，我们现在暂时命名为Sofa Mesh。我们目前的产品都在Sofa品牌下，比如Sofa RPC，Sofa Boot等。今天我们详细介绍Sofa Mesh这个单独产品，上次大会只是简单披露，也就是给大家介绍说我们有这样一个产品，而我今天的内容是把这个产品详细展开。主要是三个内容：一是Sofa Mesh的技术选型，二是它的架构设计，以及在最后跟大家聊一下，蚂蚁金服在Sofa Mesh上的开源策略。 第一个是技术选型。 先上来一堆要求，刚才我们提到过的，因为是大规模，而蚂蚁金服的体量，大家可以想象到的。实际上在性能，稳定性上，我们的衡量标准，我们考虑的基石，都是以蚂蚁金服这样的一个规模来考虑的。
在这样一个规模下，我们会涉及到一些跟其他公司不太一样的地方，比如说：我们在性能的考量上会比较重一些。因为如果性能不高的话，可能没法支撑我们这样一个规模。在考虑性能的时候，就有另外一层考量：架构和性能之间的这个权衡和取舍是要非常谨慎的。性能要求不太高的情况下，架构可能的选择，和需要比较高性能的情况下，可能会有完全不一样的取舍。稳定性就不必说了。 部署方面的要求，首先是我们会用于多种场合： 主站是指我们蚂蚁金服内部，比如大家用的最多的支付宝。 金融云，可能有一部分和我们有联系的同学会有所了解，这个是我们推出的针对金融行业的云。 然后还有我们的外部客户 部署上会要求这三个场合都能使用。 部署环境也会有多种，刚才我们调查到，有部分同学相对比较前沿一些，现在就已经上k8s了。有部分同学还是停留在以前的虚拟机以及物理机这种状态，也有一部分自己上了容器，还有部分同学可能会使用不同的公有云和私有云。这几种不同的环境，我们都是需要满足的。 第三点可能要特殊一些，需要满足各种体系。刚才我们在调查的时候了解到，有部分同学是在做旧有系统改造，那在改造的时候就会遇到一个问题：除了Service Mesh之外，还需要跟原来的体系，比如说Sofa，或者社区主流框架如Dubbo，Spring Cloud，相互之间打通和过渡。怎么在技术转型期间平滑的让业务做变更，是我们在整个技术选型之前提出的实际要求。整个技术选型是在这样一个背景下进行的。 我们做技术选型的时候，有两大方向： 一个选择是在开源产品上做 我们先看右边的路线，起点是找一个开源产品，fork出来，做增强/扩展/定制，和内部集成。因为开源产品还在继续往前走，所以我们会持续做版本更新，也可以从社区拿到最新版本。相当于是从开源社区做获取，然后接下来做反馈，让我们的一些产品，我们做的东西反馈回去。 这条路线比较大的好处是从一开始就可以得到社区的支持，社区往前走的时候也跟着往前走。如果做的比较好，愿意让自己的产品反哺社区，那么社区也可以从中受益。
微服务框架的设计与实现① 张晶1, 黄小锋2, 李春阳3 1(北京中电普华信息技术有限公司, 北京100192) 2(中国电建集团国际工程有限公司, 北京100048) 3(国网信息通信产业集团有限公司, 北京100031) 摘 要: 相对于传统单块架构, 微服务框架具有技术选型灵活, 独立部署, 按需独立扩展等优点, 更适合当前互联网时代需求. 但微服务架构的使用引入了新的问题, 如服务注册发现、服务容错等. 对微服务框架引入的问题进行分析, 并给出了微服务框架的一种实现方案, 在框架层面解决服务注册发现、服务容错等共性问题, 使业务系统开发人员专注于业务逻辑实现, 简化系统开发的难度, 提高开发效率. 关键词: 微服务框架; 服务注册; 服务发现; 服务容错 Design and Implementation of Microservice Architecture ZHANG Jing1, HUANG Xiao-Feng2, LI Chun-Yang3 1(Beijing China Power Information Technology Co. Ltd., Beijing 100192, China) 2(PowerChina International Group Limited, Beijing 100048, China) 3(State Grid Information & Telecommunication Industry Group Co. Ltd., Beijing 100031, China) Abstract: Compared with traditional single block architecture, microservice architecture has many advantages, such as flexible technology selection, independent deployment, and independent scalability more suitability for the current needs of the internet age, etc. But microservice architecture also introduces new problems such as service registration, service discovery, service fault tolerance. On the basis of the analysis for problems mentioned above, this paper proposes one implementation of microservice framework, which can solve service registration, service discovery, service fault tolerance and other common problems. Based on this, developers only need to focus on the development of business functions, so that it can simplify the difficulty of system development and improve development effectiveness. Key words: microservice architecture; service registration; service discover; fault tolerance 传统信息化系统的典型架构是单块架构(Monolithic Architecture), 即将应用程序的所有功能都打包成一个应用, 每个应用是最小的交付和部署单元, 应用部署后运行在同一进程中. 单块架构应用具有IDE友好、易于测试和部署等优势, 但是, 随着互联网的迅速发展, 单块架构临着越来越多的挑战, 主要表现在维护成本高、持续交付周期长、可伸缩性差等方面[1]. 微服务架构(Microservices)的出现以及在国内外的成功应用, 成为系统架构的一种新选择. 很多大型宝等都已经从传统单块架构迁移到微服务架构[2]. 微服务架构提倡将单块架构的应用划分成一组小的服务, 互联网公司如Twitter、Netflix、Amazon 、eBay、淘服务之间互相协调、互相配合, 为用户提供最终价值. 1 微服务架构 微服务架构是一种架构模式, 采用一组服务的方式来构建一个应用, 服务独立部署在不同的进程中, 不同服务通过一些轻量级交互机制来通信, 例如RPC、HTTP等, 服务可独立扩展伸缩, 每个服务定义了明确的边界, 不同的服务甚至可以采用不同的编程语言来实现, 由独立的团队来维护[3]. 相对于传统的单体应用架构, 微服务架构具有单个服务易于开发、理解和维护; 复杂度可控; 技术选 ①收稿时间:2016-09-18;收到修改稿时间:2016-11-03 [doi: 10.15888/https://www.doczj.com/doc/5216512677.html,ki.csa.005796]
论微服务架构及其应用 摘要 2016年7月，我所在的公司为全国各级人民检察院开发了行贿犯罪档案互联网查询系统的产品，我担任系统架构师职务，主要负责软件架构和安全体系设计的工作，该项目是基于互联网，为单位、企业和个人等公众群体提供7*24小时的查询申请服务，同时兼顾行贿犯罪预防宣传。本文结合作者的实践，以行贿犯罪档案互联网查询系统为例，论述微服务架构及其应用。首先概述我参与管理和开发，并采用微服务架构开发的工作，然后具体描述微服务架构的特点，最后结合项目描述软件的架构，说明该系统是如何采用微服务架构模式的，并说明采用微服务架构模式后，在软件开发过程中遇到的实际问题和解决方案。经过项目组近一年的努力，本产品已顺利开发完成，目前，已在浙江、云南等多省上线使用，取得客户和公司领导的一致好评。 正文 近年来，随着互联网行业的迅猛发展，公司或组织业务的不断扩张，需求的快速变化以及用户量的不断增加，传统的单块（Monolithic）软件架构面临着越来越多的挑战，已逐渐无法适应互联网时代对软件的要求。在这一背景下，微服务架构模式(Microservice Architecture Pattern)逐渐流行。它强调将单一业务功能开发成微服务的形式，每个微服务运行在一个进程中；采用HTTP等通信协议和轻量级API实现微服务之间的协作与通信。这些微服务可以使用不同的开发语言以及不同数据存储技术，能够通过自动化部署工具独立发布，并保持最低限制的集中式管理。 2015年7月，我所在的公司为全国各级人民检察院开发了行贿犯罪档案互联网查询系统的产品，我担任系统架构师职务，主要负责软件架构和安全体系设计的工作。本文结合作者的实践，论述微服务架构及其应用。首先概述我参与管理和开发，并采用微服务架构开发的工作，然后具体描述微服务架构的特点，最后结合项目描述软件的架构，说明该架构是如何采用微服务架构模式的，并说明采用微服务架构模式后，在软件开发过程中遇到的实际问题和解决方案。
微服务系统和数据库设计方案 1.微服务本质 微服务架构从本质上说其实就是分布式架构，与其说是一种新架构，不如说是一种微服务架构风格。 简单来说，微服务架构风格是要开发一种由多个小服务组成的应用。每个服务运行于独立的进程，并且采用轻量级交互。多数情况下是一个HTTP的资源API。这些服务具备独立业务能力并可以通过自动化部署方式独立部署。这种风格使最小化集中管理，从而可以使用多种不同的编程语言和数据存储技术。 对于微服务架构系统，由于其服务粒度小，模块化清晰，因此首先要做的是对系统整体进行功能、服务规划，优先考虑如何在交付过程中，从工程实践出发，组织好代码结构、配置、测试、部署、运维、监控的整个过程，从而有效体现微服务的独立性与可部署性。 本文将从微服务系统的设计阶段、开发阶段、测试阶段、部署阶段进行综合阐述。 理解微服务架构和理念是核心。 2.系统环境
3.微服务架构的挑战 可靠性： 由于采用远程调用的方式，任何一个节点、网络出现问题，都将使得服务调用失败，随着微服务数量的增多，潜在故障点也将增多。 也就是没有充分的保障机制，则单点故障会大量增加。 运维要求高： 系统监控、高可用性、自动化技术 分布式复杂性： 网络延迟、系统容错、分布式事务 部署依赖性强： 服务依赖、多版本问题 性能（服务间通讯成本高）： 无状态性、进程间调用、跨网络调用 数据一致性： 分布式事务管理需要跨越多个节点来保证数据的瞬时一致性，因此比起传统的单体架构的事务，成本要高得多。另外，在分布式系统中，通常会考虑通过数据的最终一致性来解决数据瞬时一致带来的系统不可用。 重复开发： 微服务理念崇尚每个微服务作为一个产品看待，有自己的团队开发，甚至可以有自己完全不同的技术、框架，那么与其他微服务团队的技术共享就产生了矛盾，重复开发的工作即产生了。 4.架构设计 4.1.思维设计 微服务架构设计的根本目的是实现价值交付，微服务架构只有遵循DevOps理念方可进行的更顺畅，思维方式的转变是最重要的。
微服务架构全解析：绝不是360度无死角 草根开发群体的大力支持正在将微服务架构的采用率推到新的高度。据红帽公司中间件专家Mark Little博士声称，微服务是个好东西，却不是世界和平的答案。 红帽公司中间件部门工程副总裁Mark Little博士：采用微服务并不意味着你那架构差强的泥球突然变得架构很好。 鉴于微服务的人气扶摇直上，那些记性不好的人可能忽略了这种方法极其类似面向服务的架构(SOA)，20年前SOA第一次出现在世人眼前。 不过红帽公司中间件部门工程副总裁Mark Little博士喜欢将微服务看成面向服务的架构中的精华部分，它得益于出现了更先进的工程和运维技术及技巧。 Little说：“区别就在于，推动它的主要是开发软件和分布式软件领域的新方法。Linux容器等技术――Docker就是个典例。你现在有了不变的服务，有了Kuberneters之类用于协调那些服务的技术――很显然，你有了开发运维(DevOps)，而开发运维受到敏捷开发理念的重大影响。” “那些技术让人们真正回顾我们在过去开发分布式系统的方法，面向服务的架构就是这方面的一个例子，并挑选与那些技术相匹配的精华部分。或者反之亦然，找到与面向服务的架构的一些精华部分相匹配的那些技术。这可能就是区别所在。架构方法并非不一样，但是其背后的技术确实不一样。” 在微服务架构中，应用程序组装成一组小小的半自主式进程，这些进程执行特定的任务，并使用API彼此进行联系。微服务旨在易于使用、灵活扩展，在Web应用程序、移动应用程序和物联网应用程序中日益崭露头角。 在面向服务的架构的以往不足中，Little提到了一个不足：无法在客户机和服务之间提供很好的契约定义，他还提到了Web服务描述语言(WSDL)的不足，这种语言对松散耦合、分布式的系统而言差强人意。 然而，就因为许多因素和技术融合到一起，让微服务成为当下风光无限的架构，并不能保证它就能一帆风顺。 Little说：“认识到微服务不是世界和平的答案，这一点很重要。它对一些任务来说很好。但是它跟任何技术一样，也有缺点。就因为你采用了微服务，并不突然意味着你那架构差劲的泥球(ball of mud)突然架构变得很好，不再是泥球。它有可能变成了好多分布式泥球。”“这让我有点担忧。我长期以来就在关注面向服务的架构，知道优点和缺点。我喜欢微服务，因为它让我们得以关注优点，但是人们以为它能解决根本就解决不了的许多问题，这确实让我担心。” 如果你正在考虑微服务，最好从良好的软件工程实践开始入手。 Little说：“从根本上来说，这正是面向服务的架构背后的思想。如果你不从那方面开始入手，无论你使用Docker、虚拟化、Java虚拟机还是使用其他什么都不重要，合适的工具不会为你解决架构问题。” 微架构或者甚至面向服务的架构真正发挥所长的地方在于，应彼此独立部署的逻辑服务，这些逻辑服务可以独立于其他服务进行扩展，而且能够实现独立的故障切换。 Little说：“我在微服务方面担心的问题之一就是，你有一个整体式系统(monolith)，假设你开始把它分解成多个服务，可是分解时很随意，到头来就会分解得过细，最后会有10个、
微服务架构的部署本文从以下几个方面简要说明微服务架构项目的实践经验：架构选型、开发测试环境下的相关工具支持、人员分工及开发部署流程、相关设计及注意事项。最后，将根据实践经验讨论提高微服架构下的开发和运维效率的切实需求，进一步理清本项目所实现的容器服务管理平台的完善性需求。 本项目是一个企业级的容器服务管理平台，该平台的功能是基于容器实现的应用运行环境管理，以及应用开发阶段的持续集成和持续发布。简单的理解该平台的核心功能之一就是管理复杂应用的开发和运维环境，提高微服务架构下的开发和运维效率。项目的开发背景如下： 首先，该系统具有典型分布式应用系统特征： 该平台所运行的服务器配置不高，例如华为RH1288这类低配置服务器，允许硬件失败； 系统平台要求可根据实际用户数的规模进行伸缩部署，保证硬件资源的合理利用； 由于系统平台之上需要运行若干企业应用的开发和运行环境，可靠性是非常重要的，不允许单点失效。 其次，本系统功能复杂，从架构的角度需要将系统分成多个层次和若干个子系统。不同的层次、子系统根据具体情况需要采用不同的开发语言，由不同的开发小组完成。 第三，项目组成员由几个城市的异地团队协同开发，统一的开发环境和协同工具是必不可少的。 针对上述项目背景的考虑，本项目选择基于微服务架构进行项目开发。 开发、测试、部署使用到的工具集 “工欲善其事、必先利其器”，借助适合的流程和相关工具集，才能提高微服务架构下的应用开发效率。本项目利用DevOPs流程并选用一套相关工具集实现应用开发管理，提高开发、测试、部署的效率。 代码库：本项目使用分布式代码库Gitlab，它的功能不限于代码仓库，还包括reviews(代码审查), issue tracking(问题跟踪)、wiki等功能，是代码管理和异地团队沟通、协作工具的首选。 Docker镜像仓库、Docker：本项目用容器贯穿整个软件开发流程，以容器作为应用发布的载体，应用的开发环境和测试发版环境都运行在Docker容器中。对于复杂的开发和运维环境管理Docker具有先天的优势，目前国内外的互联网公司有大多数都已经将Docker应用到了他们的开发或者生产环境中了。 K8s：本项目采用Kubernates作为容器调度管理的基础环境，开发环境、测试环境的Docker容器都由K8s负责调度管理。 Jenkins：快速的部署发布离不开老牌持续集成明星Jenkins，本项目通过Jenkins任务构建代码、将应用打包成Docker镜像，最终发布到K8s环境中将容器运行起来。 Shell脚本：编写Shell脚本将项目打分支、发布应用等开发阶段的配置管理工作自动化，降低运维门槛、提高配置管理和运维的效率。
微服务架构设计方案
引言：“微服务”是当前软件架构领域非常热门的词汇，能找到很多关于微服务的定义、准则，以及如何从微服务中获益的文章，在企业的实践中去应用“微服务”的资源却很少。本篇文章中，会介绍微服务架构（Microservices Architecture）的基础概念，以及如何在实践中具体应用。 1.单体架构(Monolithic Architecture ) 企业级的应用一般都会面临各种各样的业务需求，而常见的方式是把大量功能堆积到同一个单体架构中去。比如：常见的ERP、CRM等系统都以单体架构的方式运行，同时由于提供了大量的业务功能，随着功能的升级，整个研发、发布、定位问题，扩展，升级这样一个“怪物”系统会变得越来越困难。单体架构的初期效率很高，应用会随着时间推移逐渐变大。在每次的迭代中，开发团队都会面对新功能，然后开发许多新代码，随着时间推移，这个简单的应用会变成了一个巨大的怪物。 图1：单体架构 大部分企业通过SOA来解决上述问题，SOA的思路是把应用中相近的功能聚合到一起，以服务的形式提供出去。因此基于SOA架构的应用可以理解为一批服务的组合。SOA带来的问题是，引入了大量的服务、消息格式定义和规范。 多数情况下，SOA的服务直接相互独立，但是部署在同一个运行环境中（类似于一个Tomcat实例下，运行了很多web应用）。和单体架构类似，随着业务功能的增多SOA的服务会变得越来越复杂，本质上看没有因为使用SOA而变的更好。图1，是一个包含多种服务的在线零售网站，所有的服务部署在一个运行环境中，是一个典型的单体架构。
单体架构的应用一般有以下特点： ?设计、开发、部署为一个单独的单元。 ?会变得越来越复杂，最后导致维护、升级、新增功能变得异常困难 ?很难以敏捷研发模式进行开发和发布 ?部分更新，都需要重新部署整个应用 ?水平扩展：必须以应用为单位进行扩展，在资源需求有冲突时扩展变得比较困难（部分服务需要更多的计算资源，部分需要更多内存资源） ?可用性：一个服务的不稳定会导致整个应用出问题 ?创新困难：很难引入新的技术和框架，所有的功能都构建在同质的框架之上 2.微服务架构（Microservices Architecture） 微服务架构的核心思想是，一个应用是由多个小的、相互独立的、微服务组成，这些服务运行在自己的进程中，开发和发布都没有依赖。 多数人对于微服务的定义是， 把本来运行在单体架构中的服务拆分成相互独立的服务，并运行在各自的进程中。在我看来，不仅如此。最关键的地方在于，不同的服务能依据不同的业务需求，构建的不同的技术架构之上，并且聚焦在有限的业务功能之上。 因此，在线零售网站可以用图2的微服务架构来简单概括。基于业务需求，需要增加一个账户服务微服务，因此构建微服务绝不是在单体架构中把服务拆分开这么简单。
什么是微服务？就目前而言，对于微服务业界并没有一个统一的、标准的定义。但通常在其而言，微服务架构是一种架构模式或者说是一种架构风格，它提倡将单一应用程序划分成一组小的服务，每个服务运行独立的自己的进程中，服务之间互相协调、互相配合，为用户提供最终价值。服务之间采用轻量级的通信机制互相沟通（通常是基于 HTTP 的 RESTful API ) 。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建，可以有一个非常轻量级的集中式管理来协调这些服务。可以使用不同的语言来编写服务，也可以使用不同的数据存储。 总结了以下几点： ①小服务 小服务，没有特定的标准或者规范，但他在总体规范上一定是小的。 ②进程独立 每一组服务都是独立运行的，可能我这个服务运行在 Tomcat 容器，而 另一个服务运行在 Jetty 上。可以通过进程方式，不断的横向扩展整 个服务。 ③通信 过去的协议都是很重的，就像 ESB，就像 SOAP，轻通信，这意味着相 比过去更智能更轻量的服务相互调用，就所谓 smart endpoints and dumb pipes。
这些 Endpoint 都是解耦的，完成一个业务通信调用串起这些 Micro Service 就像是 Linux 系统中通过管道串起一系列命令业务。 过去的业务，我们通常会考虑各种各样的依赖关系，考虑系统耦合带来 的问题。微服务，可以让开发者更专注于业务的逻辑开发。 ④部署 不止业务要独立，部署也要独立。不过这也意味着，传统的开发流程会 出现一定程度的改变，开发的适合也要有一定的运维职责。 ⑤管理 传统的企业级 SOA 服务往往很大，不易于管理，耦合性高，团队开发 成本比较大。 微服务，可以让团队各思其政的选择技术实现，不同的 Service 可以 根据各自的需要选择不同的技术栈来实现其业务逻辑。 微服务的利与弊 ?优点是每个服务足够内聚，足够小，代码容易理解这样能聚焦一个指定的业务功能或业务需求。 ?开发简单、开发效率提高，一个服务可能就是专一的只干一件事。 ?微服务能够被小团队单独开发，这个小团队是 2 到 5 人的开发人员组成。?微服务是松耦合的，是有功能意义的服务，无论是在开发阶段或部署阶段都是独立的。 ?微服务能使用不同的语言开发。 ?易于和第三方集成，微服务允许容易且灵活的方式集成自动部署，通过持续集成工具，如 Jenkins，Hudson，bamboo。 ?微服务易于被一个开发人员理解，修改和维护，这样小团队能够更关注自己的工作成果。无需通过合作才能体现价值。微服务允许你利用融合最新技术。 ?微服务只是业务逻辑的代码，不会和 HTML，CSS 或其他界面组件混合。?每个微服务都有自己的存储能力，可以有自己的数据库，也可以有统一数据库。 总的来说，微服务的优势，就是在于，面对大的系统，可以有效的减少复杂程度，使服务架构的逻辑更清晰明了。 但是这样也会带来很多问题，就譬如分布式环境下的数据一致性，测试的复杂性，运维的复杂性。 什么组织适合使用微服务？ 微服务带了种种优点，种种弊端，那么什么组织适合使用微服务？ ①墨菲定律（设计系统）和康威定律（系统划分） 设计系统的组织，其产生的设计等同于组织之内、组织之间的沟通结构。
142 ?电子技术与软件工程 Electronic Technology & Software Engineering 计算机技术应用 ? the Application of Computer Technology 【关键词】微服务 Spring Cloud 分布式 早期的系统开发，都采用了单体应用模式，比如淘宝、京东、豆瓣网等，这种模式是比较适合公司创业初期的，因为比较简单，一个工程，一个数据库，最后整体打包发布就上线了。但随着业务的发展，特别是系统的访问量、数据量的急剧增加，单体应用已经无法满足业务需求，因此将庞大的单体应用按照某种维度进行拆分，进行分布式部署，为了让这种分布式系统更加的规范、更容易管理，便形成了各种服务化的方式和工具，从基于ESB 的SOA （面向服务）的基础架构到当前流行的微服务架构模式，都是在不断适应越来越复杂的应用系统。 1 微服务简介 1.1 什么是微服务 微服务是一种新兴的软件架构模式，它把一个大型的单体应用或服务拆分为多个支持微服务。一个微服务的策略可以让工作变得更为简便，它可扩展单个组件而不是整个应用程序堆栈，从而满足服务等级协议。微服务最重要的就是这个“微”字，怎样才能成为“微服务”呢，其实没有标准，这要根据系统的实际功能需求而定，并不是拆分得越细越好，应该在业务层面上去划分，能够满足各方面的需求。1.2 微服务的特点 1.2.1 微服务的优势 1.2.1.1 单个服务容易开发和维护 相比传统的单体应用，单个微服务的功能更加单一，只关注特定的功能实现，因此，在开发和维护上不需要多方的协调以及冗长的业务流程。 1.2.1.2 服务可以独立部署和扩展 微服务的开发、部署和维护都是相对独立的，互不干扰，服务之间通过标准的接口进行交互，可以很方便的对服务进行扩容。1.2.1.3 可以由不同的团队来开发 在微服务的整体架构上，通常都是按照业务进行服务划分，可以由不同的团队进行开发，服务间通过接口进行交互。1.2.1.4 服务开发技术的选项更加灵活 每个服务的技术选型都可以由相应的团队决定，可以尝试各种最新技术，更加的灵活。1.2.2 微服务的不足 1.2.2.1 管理微服务是一件麻烦的事情 基于Spring Cloud 微服务架构的应用 文/李娜 单个服务的开发和维护相对来说是很容易的，但从整个系统上看，这是一件很麻烦的事情，因为系统从单体变成了分布式，多个服务分布在不同的服务器中，需要完善的服务监控和管理的能力。 1.2.2.2 来自分区数据库带来的实现问题 每一个服务都有自己的数据库，这样才能达到真正系统微服务化的目的。由此会带来一个最为突出的问题就是分布式事务，实现上可以选择按照ACID 的强一致性或者基于BASE 理论的最终一致性。 1.2.2.3 服务间调用的成本更高 由于服务都是分布式部署，服务之间的调用相比传统的本地方法调用，需要更大的成本，调用过程中还会遇到安全、网络抖动等外在的问题。 2 微服务的实现方式 微服务并不是一种技术或者框架，而是一种设计理念或者架构模式，它基于模块化、组件化等架构思想。微服务的实现方式，目前主要有两种，一种是基于RPC 的方式，另一种是基于HTTP 的Restful 方式，这两种实现方式各有利弊，可以选择其中的一种，也可以将两种结合起来使用。在实际应用中，系统内部服务之间的调用通过RPC 方式，可以满足对性能方面的需求；面向客户端以及对外的服务输出采用Restful 方式，一是调用简单，二是更加标准，降低调用成本。 3 Spring-Cloud的技术架构 Spring Cloud 是一种基于Spring Boot 的微服务框架，它实现了微服务架构中常用的组件，目前比较常用的组件是基于Net?ix 对多个开源组件的封装，为微服务架构开发涉及的配置管理、服务治理、熔断机制、智能路由、微代理、控制总线、一次性token 、全局一致性锁、leader 选举、分布式session 、集群状态管理等操作提供了一种简单的开发方式，spring-cloud 的基础架构如图1所示。3.1 网关 接受外部对服务接口的访问，屏蔽底层服务的具体实现，提供权限、认证、安全、监控、限流等基础服务，常见的有Zuul 、spring-cloud-gateway 。3.2 Ribbon Spring-Cloud-Ribbon 是基于HTTP 和TCP 的客户端负载均衡工具，它基于Net?ix Ribbon 实现，可以轻松地将面向服务的REST 模版请求自动转换成客户端负载均衡的服务调用。3.3 Eureka Spring-Cloud-Eureka 是对Net?ix Eureka 的封装以实现服务发现功能，它包含了Server 端和Client 端。Eureka Server 提供服务注册功能，各个节点启动后，会在Eureka Server 中 进行注册；Eureka Client 用于简化与Eureka Server 的交互，可以方便地访问注册中心的服务。3.4 Hystrix Hystrix 是一种熔断器，实现服务的限流、熔断、降级等功能，可以很好的保证服务在高并发情况下的稳定性。 4 微服务应用场景 任何的架构模式都需要根据实际的业务场景而定，不能盲目的追求最新的技术，最适合的就是最好的。对于微服务而言，以下的场景或者条件是比较适合的。 系统业务量越来越大，核心业务和非核心业务变得泾渭分明，这个时候将你的业务系统拆分为细颗粒的服务进行管理，通过断路由、降级、限流等服务管理措施保证系统高可用。 开发团队具有足够的实力，包括系统架构、开发、运维等方面，可以解决微服务带来的各种问题，充分利用好微服务带来的好处。 5 结论 综上所述，相对于传统的单体应用，微服务带来了系统整体架构上的转变，也给系统的设计和开发带来了很多好处，但也不可避免的存在一些问题，这需要根据系统自身业务场景来选择适合自己的架构模式。 参考文献 [1]不甘于平凡的溃败的博客.微服务初 探.https://https://www.doczj.com/doc/5216512677.html,/wohiusdashi /article/details/83957771 [2]李忠民,齐占新.业务架构的微应用化与 技术架构的微服务化--兼谈微服务架构的实施实践[J].科技创新与应用,2016.[3]王玉良.基于Spark 的短时交通流预测系 统设计[J].桂林电子科技大学,2017.[4]赵善龙,孙婉婷.基于微服务架构的互 联网+农业平台设计[J].通信管理与技 术,2017. 作者简介 李娜（1988-），女，山东省新泰市人。研究生学历。主要研究方向为计算机应用技术。 作者单位 重庆青年职业技术学院 重庆市 400712 图1：Spring-cloud 基础架构图