简介
微服务是软件开发中把一个单一的应用按业务功能分解成多个职责单一的“微小”服务的架构方法。
每一个服务都有其独特且定义良好的角色，有自己的进程，并利用轻量化机制（通常为 HTTP RESTful API）实现通信。
在同一应用中，每个微服务都围绕着具体业务进行构建，可以独立于同级其他的服务，进行部署、升级、扩展和重启。
它们通常由自动化系统进行编排，使得在不影响最终用户的情况下，对实时应用程序的频繁更新成为可能。
"微服务"强调的是服务的大小，关注的是某一个点。
"微服务架构"则是一种架构思想和模式，需要从整体上对软件系统进行通盘的考虑，提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。
换而言之，微服务架构就是将应用程序构建为一套服务。
每个服务都有各自的边界，都可以独立部署和扩展，可以采用不同的技术栈（不同的编程语言，不同的数据库等），可以由不同的小团队开发和维护。
在微服务架构下，每个服务的问题基本都可以在职能俱全的小团队内部得到快速解决，减少沟通和协调的成本。
这个团队应该从“产品的角度”，负责产品的整个生命周期，而不是但从“项目的角度”，交付完成后，就解散，从此各不相关。
一个持续产品生命周期的团队，时刻关注他们的产品状态，增加客户联系，同时承担一些售后支持，是能够帮助软件和客户提升业务能力的。
微服务类似乐高积木，可以拼在一起搭建一个标准模型。
首先，开发人员需要识别项目需要哪些单独的服务，例如搜索，认证，消息传递等。
然后，从开源到成套的企业解决方案之间做选择，最后把所有东西整合成一个应用。
换句话说，微服务使开发人员不必在已经解决的技术问题上再浪费时间，重复造轮子。
团队中的每个开发人员只需专注自己那部分工作，无需关注底层的基础架构。
如果在生产中，拼在一起的各个模块不能很好的工作，则很容易将它们隔离，拆开并重新配置
微服务可以在容器内运行，也可以作为完整的虚拟机运行。
也就是说，像Docker和Kubernetes这样基于容器的开源系统，是开发、部署和管理微服务的一种非常有效的方式。
围绕容器产生的众多成熟和强大的工具、平台及各种服务，使得容器化天生就适合微服务应用。
微服务架构也有缺点：
微服务的远程调用会比单一应用的进程内调用消耗更多的资源，而且在组织上也会更复杂，面临更多的挑战，但随着应用复杂度的提升，微服务架构的威力也会逐渐显现。
相对一体化的应用，需要一些额外的基础设施，例如部署流水线、监控（日志、指标收集）等
团队成员也需要实现或解决新的关注点：
- 微服务间的额外跳转导致网络延迟增加
- 低延迟身份认证和授权
- 独立部署和回滚
- 良好定义的接口：功能聚焦的同时，兼顾扩展
- 无状态的业务逻辑
- 依赖关系
- 工具和过程
- 。。。。。。
但随着应用复杂度的提升，经验的累积，这些挑战将变得越来越少，微服务架构的威力也会逐渐显现。
初见
其他
Service Mesh
简介
Service Mesh被翻译为“服务网格”，或者“服务啮合”， 很多人将之称为下一代微服务，或直接称之为微服务2.0。
微服务的概念在2014年3月由Martin Fowler首次提出，Service Mesh的概念则是在2016年左右提出。
微服务1.0时代的主要问题主要包括如下三方面：
技术门槛高：
开发团队在实施微服务的过程中，除了基础的服务发现、配置中心和鉴权管理之外，团队在服务治理层面面临了诸多的挑战，包括负载均衡、熔断降级、灰度发布、故障切换、分布式跟踪等，这对开发团队提出了非常高的技术要求。
多语言支持不足：
对于互联网公司，尤其是快速发展的互联网创业公司，多语言的技术栈、跨语言的服务调用也是常态，但目前开源社区上并没有一套统一的、跨语言的微服务技术栈，而跨语言调用恰恰是微服务概念诞生之初的要实现的一个重要特性之一。
代码侵入性强：
Spring Cloud、Dubbo等主流的微服务框架都对业务代码有一定的侵入性，技术升级替换成本高，导致开发团队配合意愿低，微服务落地困难。
Sidecar是Service Mesh中的重要组成部分，Sidecar的精髓在于实现了数据面（业务逻辑）和控制面的解耦。
在Service Mesh架构中，给每一个微服务实例部署一个Sidecar Proxy。该Sidecar Proxy负责接管对应服务的入流量和出流量，并将微服务架构中的服务订阅、服务发现、熔断、限流、降级、分布式跟踪等功能从服务中抽离到该Proxy中。
Sidecar以一个独立的进程启动，可以每台宿主机共用同一个Sidecar进程，也可以每个应用独占一个Sidecar进程。
所有的服务治理功能，都由Sidecar接管，应用的对外访问仅需要访问Sidecar即可。
当该Sidecar在微服务中大量部署时，这些Sidecar节点自然就形成了一个服务网格。
Service Mesh至今也经历了第二代的发展。
第一代Service Mesh的代表为Linkerd和Envoy，这两个开源实现都是以Sidecar为核心，绝大部分关注点都是如何做好Proxy，并完成一些通用控制面的功能。
Envoy底层基于C++，性能上优于使用Scala的Linkrd。同时，Envoy社区成熟度较高，商用稳定版本面世时间也较长。
但是当在容器中大量部署Sidecar以后，如何管理和控制这些Sidecar本身就是一个不小的挑战。
第二代Service Mesh主要改进集中在更加强大的控制面功能（与之对应的Sidecar Proxy被称之为数据面），典型代表有Istio和Conduit。
Istio是Google、IBM和Lyft合作的开源项目，是目前最主流的Service Mesh方案，也是事实上的第二代Service Mesh标准。在Istio中，直接把Envoy作为Sidecar。除了Sidecar，Istio中的控制面组件都是使用Go语言编写。
对于大规模部署微服务，内部服务异构程度高的场景，使用Service Mesh方案是一个不错的选择。
Service Mesh实现了业务逻辑和控制的解耦，但是也带来了额外的开销，由于网络中多了一跳，增加了性能的损耗和访问的延迟。
同时，由于每个服务都需要部署Sidecar, 这也会使本来就具有一定复杂度的分布式系统变得更加复杂。
尤其是在实施初期，对Service Mesh的管理和运维会是一个棘手的问题。
因此，当选择使用Service Mesh架构的时候，需要对具体的Service Mesh实现方案（例如：Istio）做好充分的技术准备和经验积累工作，方能确保方案的顺利实施。
初见
- 全方位详解Service Mesh（服务网格）： https://www.infoq.cn/article/hTzq7h1cPxWFGsiLkBkJ
- Service Mesh Interface详细介绍： https://www.infoq.cn/article/Xdi_zXgeAVzI1ABJWhBY
- Service Mesh和API Gateway关系深度探讨： https://www.infoq.cn/article/4FJXNTHJMio6g75uSX0h
- Service Mesh 系列： https://www.infoq.cn/profile/00DFA998449A6B
Serverless
简介
在微服务与容器技术火热之后，Serverless（无服务器架构）成为新的热点，无服务器云函数可以让用户无需关心服务器的部署运营，只需开发最核心的业务逻辑，即可实现上线运营，具备分布容灾能力，可以依据负载自动扩缩容，并按照实际调用次数与时长计费。
但Serverless 并不意味着没有任何服务器去运行代码，Serverless是无需管理服务器，只需要关注代码，而提供者将处理其余部分工作。
“无服务器架构”也可以指部分服务器端逻辑依然由应用程序开发者来编写的应用程序，但与传统架构的不同之处在于，这些逻辑运行在完全由第三方管理，由事件触发的无状态（Stateless）暂存于计算容器内。
Serverless架构可以认为是对微服务和容器化的一种补充，为用户提供了一种新的选择，来应对复杂多变的需求，尤其适合快速发展的初创型公司。
对于开发者来说:
Serverless架构可以将其服务器端应用程序分解成多个执行不同任务的函数，整个应用分为几个独立、松散耦合的组件，这些组件可以在任何规模上运行。
使用Serverless架构可以免除所有运维性操作，开发人员可以更加专注于核心业务的开发，实现快速上线和迭代，把握业务发展的节奏。
常见的Serverless架构:
所有的服务都以FaaS（函数即服务）的方式对外进行提供。
在语言和环境方面，FaaS 函数就是常规的应用程序，例如使用JavaScript、Python以及 Java等语言实现。
Serverless架构优势
### 缩短交付时间
Serverless架构允许开发人员在极短时间内（几小时、几天）交付新的应用程序，而不是像以前一样需要几个星期或几个月。
在新的应用程序中，依赖于第三方API提供服务的例子很多，如认证(OAuth)、社交、地图、人工智能等。
### 增强可伸缩性
所有人都希望自己开发的应用能够快速获取大量的新增用户，但是当活跃用户快速增长的时候，服务器的压力也会激增。
使用Serverless架构的体系不再有上述担忧，可以及时、灵活进行扩展来应对快速增长的活跃用户带来的访问压力。
### 降低成本
Serverless架构模式可以降低计算能力和人力资源方面的成本，如果不需要服务器，就不用花费时间重新造轮子、风险监测、图像处理，以及基础设施管理，操作成本会直线下降。
### 改善用户体验
用户通常不太关心基础设施，而更注重于功能和用户体验。Serverless架构允许团队将资源集中在用户体验上。
### 减少延迟及优化地理位置信息
应用规模能力取决于三个方面：用户数量、所在位置及网络延迟。
当应用要面向全国甚至全球用户的时候，通常会产生较高的延迟，从而降低用户体验。
在Serverless架构下，供应商在每个用户附近都有节点，大幅度降低了访问延迟，因此所有用户的体验都可以得到提升。
初见
SCF（Serverless Cloud Function）
- 基本概念入门：https://www.infoq.cn/article/s101GtcCV05_2AgKo8GD
- 运行原理与组件架构：https://www.infoq.cn/article/ojdHHzHVrh3TpNRAX7qR
- 开发者工具建设：https://www.infoq.cn/article/kOVzg4OOxJUZfYRPGT2d