微服务是什么？（什么是微服务架构）
微服务架构概述
微服务在设计之初就是致力于解决单体式架构的问题而动身的，所以它几乎可以解决单体式架构面临的所有问题。虽然微服务本身也有一些缺点，但丝毫不影响它替代单体式架构成为主流架构的步伐。那么，微服务架构到底能解决哪些问题呢？
微服务能解决的问题
下面从之前总结的单体式架构的缺陷来剖析。首先，微服务解决了难以保护的问题。微服务本身渺小的设计，导致一个服务的职责不会过大，从而轻松地解决了难以保护的问题，单对一个服务来讲，它的代码量不会特殊多，量少的东西不必定简略，但必定是好管理的，而且后续介绍的有关微服务更科学的程序设计办法，也会大大增长代码的可保护性。
其次，过载的IDE和过载的Web容器，似乎也随着服务的渺小化而轻松解决了，微服务架构中的每个服务都是独立安排的，拥有自己独立的过程，无论是IDE还是Web容器，都可以轻松地承载，而且运用程序的启动和调试效力也要高得多。
然后，对于安排，微服务架构中，服务都是主动安排的（具体的方法后续章节会有介绍），而且每个服务负责的职责都很小，只会安排有变更的服务，所以单体式架构中须要安排全体功效的风险也就没有了。
这样的方法，在运用须要做程度扩大的时候，只需增长须要的服务节点即可，再依据具体增长节点的特征，如存储、CPU、内存等增长具体的符合需求的资源，也就不会涌现资源的糟蹋了。
最后，关于技巧创新，微服务本身是独立的，而且每个微服务之间的通讯是轻量级的，这就导致微服务之前几乎是没有技巧依附和限制的，服务既可以有自己独立的存储方法，也可以有不同的语言，服务所采取的技巧栈也可以是完整不一样的。所以，你几乎可以应用任何你以为适合的技巧，当然，做技巧选型往往可能须要斟酌更多的问题，但至少在项目标服务架构层面，微服务并不会对一个项目标技巧选择造成什么困扰。
看上去微服务似乎真的解决了单体式架构的所有问题，那除了能解决这些问题，微服务本身又有哪些新的特色呢？
微服务架构百思特网的特色
微服务定义大致反应出微服务架构的一些特色：微服务是小的服务；微服务是独立运行的；微服务的交互是轻量级的，是可以跨语言的；服务的设计是环绕业务的；微服务是可以主动安排的，有集中式的服务管理等。
但随着微服务的发展，它的定义是多变的，每个人在应用微服务架构时的做法都不完整一样，其中有很多很好的实践，有庞杂的，也有简略的，似乎很难去界定谁对谁错，究竟由于软件项目标奇特性，每种实践都是在特定的需求和场景下发生的，因此不妨把眼光放在它们的共同点上。此前有过无数人的勇敢尝试和实践，我们可以通过火析来看看大多数人都在怎样做着微服务。
ThoughtWorks的Martin Fowler是业界的威望专家，他以为虽然很难给微服务的架构一个准确的定义，但可以尝试描写我们以为有适合标签的架构的共同特点。并非所有的微服务架构都具有所有的特点，但是Martin Fowler愿望大多数微服务能具有大部分特点。最后，他总结了微服务的九大特点，成为当下这个松散的社区关于微服务的一个宽松的尺度。
下面就来看看微服务的九大特点，如图1.8所示。
1. 服务组件化
组件简略来说就是一个可以独立改换和升级的软件单元，就像盘算机的内存、显卡、硬盘一样，是可插拔的，而且改换和设计不会影响其他单元。在微服务架构设计中，我们将运用拆分为一个个独立的服务，这些服务像组件一样可以独立改换和升级。每个服务拥有独立的过程，可以独立开发和安排；每个服务可以拥有独立的存储，服务之间通过HTTP等轻量级的通讯协定进行交互，而不是传统的嵌入式的方法。
2. 环绕业务组织团队
通常，传统的公司可能会依照技巧去组建团队，如测试团队、前端开发团队、后端开发团队、数据库团队、运维团队等，但微服务本身的设计是环绕业务展开的，各个服务依照业务价值来划分边界，这样就导致了微服务的团队组织构造上是必需跨技巧才能的，一个团队中可能须要包含各种才能的人，如前业务剖析师、测试工程师、前端开发工程师、后端开发工程师、数据库工程师、UI设计师、运维工程师等。
当然，由于微服务小的设计理念，团队的范围不会很大，如亚马逊的“Two Pizza Team”原则，一个团队吃一餐饭只需两个披萨就够了。这样一个团队，工作中的内讧是很低的，因为团队的职责边界更加清楚，团队间沟通不畅或者推辞义务等现象将会得到改良。
3. 做产品而非项目
微服务架构中风行着一句话：“You build，you run it！”意思是你构建的运用，那么由你来负责运行它。
人们在传统的软件项目中，往往以一个做交付的方法来做项目，而不会斟酌全部产品的运作方法或性命周期。例如，产品将需求交付给开发，开发将运用交付给测试，测试将构建好的版本交付给运维，运维负责将运用运行起来。
微服务架构的团队组织可以说是麻雀虽小五脏俱全，一个团队往往须要负责项目标全体阶段的工作，微服务团队更像是在做产品而非项目，大家须要关注全部产品的性命周期，负责各个阶段的各种工作，并且连续关注服务的运作情形，从而不断剖析，来赞助客户晋升业务价值，提倡开发运维一体化，现在很风行的DevOps等角色，也是在微服务风行趋势下所发生的。
4. 智能端点和哑管道
由于微服务本身分别的特色，它并不能像单体式架构那样通过本地的函数调用即可进行服务间的交互，那么选择一个好的远程调用的通讯方法是症结。
在SOA中，有一些较好的实践，如在之前提到的ESB就强调须要将调用逻辑放入沟通机制本身，各个端点遵守统一的尺度，由企业服务总线来完成资讯路由、编排和转换等功效。这会导致服务间的通讯更加繁琐，笨重的调用方法在服务升级或改换时显得尤为吃力。所以，我们须要更加粗粒度、更加轻量的通讯机制。微服务社区更偏向于采取另一种办法：智能端点和哑管道。微服务在设计上不只是在意分别，还强调内聚，每个服务拥有自己的范畴逻辑，就像是UNIX的管道设计一样。目前最常用的有两种协定：一种是带有资源API的HTTP要求，即人们常说的RESTful API要求；另一种是通过轻量级的资讯总线，如应用RabbitMQ或ZeroMQ等来进行资讯传递。
5. 去中心化治理
无论是单体式架构，还是SOA，似乎都须要定义一个统一的技巧平台尺度，但经验表明，这种做法并不好，不是每个问题都是钉子，不是每个解决计划都是锤子，每种技巧平台都会有它的短板，一旦规定了统一的技巧平台尺度，在遇到它的短板时，开发者将觉得十分苦楚。
微服务团队更倡导采取不同的办法或尺度，应用准确的工具和技巧来完成工作。通过轻量级的、粗粒度的通讯机制，不同的服务不再须要中心化的技巧平台尺度，服务可以是不同语言、不同框架的，可以依据不同的业务场景须要来选择适合的技巧。
6. 疏散的数据管理
疏散的数据管理十分符合微服务最初的定义，服务间是独立运行的，每个服务都可以拥有自己独立的存储。当然，关于去中心化数据管理，业界也有很多解决计划，如模型概念上的不同，可以抽象出不同的视图，可以应用范畴驱动设计的方法（后面章节会介绍）将庞杂的范畴划分成不同的限界高低文，这有助于澄清业务边界，强化数据模型上的分别。
微服务除在概念模型上的疏散策略之外，还疏散了数据的存储决策，让每个服务管理自己的数据库，可以是雷同的数据库技巧的不同实现，也可以是完整不同的数据库体系。人们把这种方法称为“Polyglot Persistence”（多语言持久化）。
当然，这种做法也会带来一些弊病，如散布式事务等问题，往往须要通过额外的工作来保证事务的最终一致性，但是这丝毫不会阻碍其在微服务架构中的运用，微服务团队往往把这个问题的解决寄愿望于服务拆分的合理性上。
7. 基本设施主动化
微服务由于小和分别的特色，往往一个大型庞杂的项目运作须要安排很多服务，如果都是人工手动来完成这项工作，那么无疑将会消耗伟大的成本，而且人工容易出错，一旦出错，排查会十分费力，好在基本设施主动化技巧在过去几年中产生了伟大的变更，特殊是云技巧、Docker和K8s等技巧的发展，大大下降了构建、安排和运行软件的成本。各种连续集成和持久交付的工具层出不穷，而微服务架构中就须要这样的服务或技巧工具来保证服务的构建、安排和测试等工作可以做到主动化。
8. 容错设计
应用服务作为组件的成果就是须要设计的运用程序能够容忍服务的失败。由于服务供给者不可用，义务服务花费者调用此服务时都可能失败，因此服务花费者必需尽可能优雅地对此做出响应。
单体式架构在这方面似乎有必定的优势，由于都是本地函数调用，它无须引入额外的庞杂代码就可到达优雅响应的目标，但任何事情都有其多面性，单体式架构的长处是体系庞杂度下降了，但缺陷也是毋庸置疑的。也就是说，如果服务不可用，可能会影响全部运用，致使其他无关的功效都不可用。
所以，微服务架构中一般最根本的做法是针对每个服务都进行弹性的监控和日志记载，这样能够保证在服务涌现故障时迅速地监控并加以恢复。有关断路器、当前吞吐量和延迟的信息监控等其他方法，在后续的章节中详细介绍。
9. 演进式设计
现在已经知道了很多微服设计的症结因素，不难看出，要设计一个完善的微服务架构，尤其是对于没有足够经验的团队来说，无疑是很难的。但从软件设计的思路来看，没有设计从一开端就是完善的。
所以，很多情形下，微服务从业者都会以演进的方法进行体系的设计，笔者在工作中也常被项目标业务剖析师问道：为什么我看你们总在重构，就不能一开端写代码时把构造设计好吗？这时，笔者反而认为这是软件设计好的表示，然后很耐烦地和他说明软件设计的思路就是这样的。人们称其为演进式设计。
当然，重构也是须要条件的，开发人员应当能够掌握运用程序的更改，而且不会下降变革速度。变革掌握并不必定意味着转变，但可以通过准确的态度和工具，如单元测试、契约测试等，对软件进行频繁、迅速和良好掌握的更改。
微服务架构的优势
综上所述，微服务不是SOA，它能直击单体式架构的痛点，在比拟其他架构之后，懂得到了微服务的九大特征，那么，在实际运用进程中，微服务到底能带给人们哪些方便呢？与其他框架比拟，它的优势毕竟是什么呢？
当然，一个流程的架构模式必定是有很多优势的，要列举全体的微服务架构的优势不太现实，在这里列举微服架构的几个壮大优势，壮大到各大公司，如亚马逊、Netflix、eBay，包含国内的某些大公司都开端转型。
（1）微服务架构的一个主要优势在于可以做到故障隔离，运用程序可以不受单个模块故障的影响，这是软件工程尤为主要的一点，微服务是松散耦合的，各个安排单元都是独立的，加上服务监控及熔断的机制，可以轻松地保证一个体系的硬朗性。无论是运行还是安排，各个服务都可以做到完整独立。
（2）微服务架构清除了项目须要长期坚持单个技巧栈的状态，微服务的疏散式设计本身就勉励开发者在不同的场景和需求下应用最适合的技巧，而且服务本身运行的独立性和通讯的轻便性也保证了开发者在做技巧选型时不会受到太多的限制。
（3）微服务架构使新开发人员更容易上手，微服务架的庞杂性是本地化的，服务前较低的依附可以让开发人员不用过多地关注服务之外的逻辑，而只关注本地服务的业务，再加上服务本身小巧的特征，单个微服务的业务不会特殊庞杂，新开发人员很容易就能上手，对项目整体而言，也可以通过对各个服务的熟习，来逐步懂得全部体系的全貌。
（4）微服务架构除了在技巧上能带来诸多利益，在企业的组织构造上也能起到优化作用。微服务架构通常是环绕着业务进行设计的，那么它的团队也常常环绕业务的价值和优先级进行配置，从而使团队组建者能够完整专注于所分配服务的特定扩大和可用性请求。因此，团队往往是全能的、高效的，同时也是跨职能的。这样的团队也带来了外包的灵巧性，虽然许多企业主愿望能够将工作转交给第三方合作伙伴，但他们常常担忧自己的知识产权，微服务架构则可以满足企业在不披露其核心服务的情形下，将其与非核心业务功效外包的工作分割开来。
这些令人印象深入的优势使微服务看起来非常诱人，那么微服务架构就是我们要找的完善架构了？当然不是，与前文所说一样，并不是每个问题都是钉子，不是每个解决计划都是锤子，微服务架构自然也有其缺陷，而微服务架构的优势也并不是每个项目都能施展出来的，可能还取决于具体项目技巧和组织等各种内在和外在的因素。
微服务的挑衅
仅仅是因为某些事情在全部行业风靡一时，并不意味着它没有任何缺陷。相反，站在风口浪尖，微服务所面临的挑衅也不会小。微服务就是为百思特网了敷衍那些大而庞杂的项目而出生的，所以往往面对的问题都不会太简略，而且似乎很多团队在做微服务转型时都遇到了不少艰苦，其中不乏一些很有经验、很成熟的团队。
那么，应用微服务毕竟有哪些难点呢？微服务本身又有哪些缺陷呢？
应用微服务的难点
要评价一个软件架构或技巧框架的缺陷，笔者以为最直接的就是看这个架构或技巧是否好用，应用进程中的难点就代表着这个架构或技巧框架的缺陷。微服务也应当如此，微服务在应用进程中的难点如图1.9所示。
1. 散布式体系可能很庞杂
微服务的架构设计导致了它必定是散布式的，所以散布式体系的难点，几乎微服务全都有。由于一切都是组件化的，而且各个服务都是独立的，因此必需细心处置模块之间的要求，为了保证体系的硬朗性，须要专门额外的代码去监控服务的健康状况，记载和收集各种日志，否则当远程呼唤中止或延迟时，事情会变得更加庞杂。
2. 事务管理可能很苦楚
微服务具有疏散的数据管理特征，服务不仅可以拥有独立的数据存储，而且可以应用不同的技巧实现。这就导致了如果须要做到事务的一致性将变得非常艰苦，当然艰苦还是有方法解决的，如现在比拟风行的散布式事务最终一致性的解决计划等，也有不少的开源框架来做这件事。但是这无疑给体系实现增长了相当的庞杂度，而且针对这些庞杂度而发生的工作可能对用户来讲，并没有直接的业务价值。
3. 微服务的测试可能很麻烦
与单体式架构比百思特网较，微服务的测试可能很庞杂，单体式架构往往是一些外部组件依附，如数据库，而一个微服务架构的体系，往往一个完成的业务功效测试须要依附多个服务组合共同完成，而且服务之前可能会存在调用次序的依附，在某一个时光点上，同一个微服务可能具有多个版本，这无疑又增长了测试和调试的成本。
4. 运维安排请求较高
由于体系被拆分为多个服务，安排时须要懂得服务整体的关联关系，工程师除须要应用和搭建主动化技巧来进行服务安排之外，还须要对全部体系进行有效的监控。因此，DevOps的角色是必须的，而很多企业或项目，一个全职的DevOps无疑是奢靡的。
5. 通讯成本较高
微服务都采取远程的方法进行调研，通常会采取轻量级的HTTP协定或资讯机制进行通讯，所以可能在范围不大时与本地函数调用的差别不会很大，但随着项目时光的推移，体系范围的扩展，服务间的调用越来越频繁，获得单个业务成果的调用链越来越长，这时通讯成本的消费将是恐怖的。
微服务不是银弹
综上所述，微服务并不是万能的，它会有各式各样的问题，只不过目前我们尚能接收，或者说它带给我们的利益远大于这些缺陷。而且，这些问题并不是没有解决计划，究竟有些问题可能在其他架构中仍然存在。
例如，安排难度大，我们可以应用一些易用的平台或工具，来赞助迅速地搭建主动安排的流水线，如Jenkins、PaaS平台等技巧；又如，难以测试多版本的问题，可以通过WireMock等技巧清除依附，把测试做到尽可能的单元，然后树立良好的契约测试规范，保证不同版本的兼容测试；再如，散布式事务，如二段提交、补偿事务、最终一致性等计划也都比拟成熟；此外，还有服务监控和容错及日志记载等，Spring Cloud供给了相应全面的框架来实现这些功效，这些计划和技巧都会在后续章节中介绍。
当然，即使解决了这些问题，微服务仍然不能作为一个银弹，究竟软件工程本就没有银弹，甚至有人以为微服务并不能代表软件架构在未来的发展方向。我们也无法评估现在的微服务架构是否成熟，但这丝毫不会阻拦大胆的程序员摸索和寻求真谛的步伐。
我们愿望微服务变得越来越成熟，就如同愿望自己的体系组件化做得越来越好一样，至少目前看来，微服务是一条值得走的路，虽然我们无法肯定这条路最终会走到哪里，但是对事物实质和真谛的摸索及寻求技巧卓著的脚步永远不会停下。