大三的暑期实习选择去了华为西研所的数据与通信产品线，主要做安全产品开发。因为要去实习的部门涉及微服务开发，之前也简单看过一些微服务的概念，索性写一个微服务系列来对这个领域进行学习。
What & When & Why & Who & Where
一些基本术语
下面了解一些基本术语，表格来自华子的ServiceComb的开发指南。
| 缩略语 | 英文名 | 中文名 | 解释 |
|---|---|---|---|
| MicroServices | MicroServices | 微服务 | 微服务是一种清凉估计SOA架构，通常用来描述广泛用于运行用、福利往往应用的一种松耦合分布式架构。 |
| Provider | Provider | 服务提供者 | 在为服务调用关系中处于被调用一方的服务。 |
| Consumer | Consumer | 服务消费者 | 在微服务调用关系中处于调用发起方的服务。 |
| Application | Application | 应用 | 应用代表一个软件应用的逻辑实体，标识一个有业务功能呈现给用户的计算机软件应用。一个以为服务化架构构建的应用通常由多个微服务组成。 |
| Instance | Instance | 微服务实例 | 一个微服务的最小运行和部署单元，通常对应一个应用进程。 |
| IAM | Identity and Access management | 身份及权限管理 | 负责PaaS系统中股那里层级、用户、角色、授权管、用户的组织归性等信息的维护。并实施授权和授权检查。 |
| AK/SK | AK/SK | AK/SK密钥 | Access key/Secret key是一组密钥对，用于API的身份认证和访问控制。 |
| Service | Service | 服务 | 服务是对按需取用的功能对象的一种描述。再应用模型中，服务一般面向应用，应用使用服务需要先订购服务，再绑定服务并使用，某些商业场景下可能还需要按使用量付费 |
| Load Balance | Load Balance | 负载均衡 | 当应用访问一个具有多个实例的微服务时，会涉及到路由负载均衡。可以通过配置文件配置负载均衡策略，支持随机，轮询、会话保持和基于响应时间的权值等多种负载均衡路由策略。 |
| Rate limit | Rate limit | 限流 | 当资源成为瓶颈时，服务框架需要对消费者的访问请求做限流，启动流控保护机制。在服务消费者端和提供者端均可进行流量控制。在服务消费端，可以限制发往某个微服务提供者的请求频率；在服务提供端，可以限制每个微服务消费端发过来的请求频率，也可以根据服务提供端资源消耗情况确定总的请求频率限制，防止服务因资源耗尽而崩溃。 |
| Service Degrade | Service Degrade | 降级 | 服务降级主要包括屏蔽降级和容错降级两种策略：屏蔽降级是指当外界的触发条件达到某个临界值时，由运维人员/开发人员决策，对某类或者某个服务进行强制降级。容错降级是指当非核心服务不可用时，可以对故障服务做业务逻辑放通，以保障核心服务的运行。 |
| Fault tolarance | Fault tolarance | 容错 | 容错是消费者访问服务时出现异常的场景下的一种处理策略，出现异常后由服务框架自动选择新的服务路由进行调用。 |
| Circuit Breaker | Circuit Breaker | 熔断 | 微服务之间通常存在依赖关系，服务调用链路可能包含多个微服务，如果链路中一个或多个服务访问延迟过高，会导致入口服务的请求不断堆积，持续消耗更多的线程、io资源，最终由于资源累积使系统出现瓶颈，造成更多服务不可用，产生雪崩效应。熔断机制就是针对上述场景设计的，当某个目标服务响应缓慢或者有大量超时情况发生时，熔断该服务的调用，对于后续调用请求，不再继续调用目标服务，直接返回，快速释放资源，等到该目标服务情况好转再恢复调用。 |
| Isolation | Isolation | 隔离 | 服务隔离是一种异常检测机制，常用的检测方法是请求超时、流量过大等。一般的设置参数包括超时时间、最大并发请求数等，当超过超时时间或最大并发请求数时，记录一次异常，并用于在熔断机制中计算错误率和错误请求数。 |
| Service Mesh | Service Mesh | 服务网格 | 一种基础设施层服务。在微服务化的过程中，开发者需要解决应用运行在分布式网络中所引入的问题，例如容错，限流，负载均衡，注册发现，可监控等，Service Mesh作为L4/L7协议代理，为应用解决了微服务化后带来的问题。 |
| legacy | legacy | 遗留系统 | 遗留系统是一个还在运行和使用，但已步入软件生命周期衰老期的软件系统。 |
云服务模型
通常由三种云服务模型: PaaS, SaaS, IaaS。以及一个最新流行的FaaS概念，先用一张图来简单了解它们的区别：
PaaS
Platform as a Service。云平台服务或平台即服务（PaaS）为某些软件提供云组件，这些组件主要用于应用程序。 PaaS为开发人员提供了一个框架，使他们可以基于它创建自定义应用程序。所有服务器，存储和网络都可以由企业或第三方提供商进行管理，而开发人员可以负责应用程序的管理。
优点：
- 使应用程序的开发和部署变得简单且经济高效
- 可扩展
- 高度可用
- 使开发人员能够创建自定义应用程序而无需维护软件
- 大大减少了编码量
- 自动化业务策略
- 允许轻松迁移到混合模型
PaaS例子：AWS Elastic Beanstalk、Windows Azure、Heroku、Force.com、Google App Engine，Apache Stratos，OpenShift。
SaaS
Software as a Service。软件即服务（也称为云应用程序服务）代表了云市场中企业最常用的选项。 SaaS利用互联网向其用户提供应用程序，这些应用程序由第三方供应商管理。 大多数SaaS应用程序直接通过Web浏览器运行，不需要在客户端进行任何下载或安装。
优点：
- 大大减少了安装，管理，升级软件等繁琐任务所花费的实践和金钱
SaaS例子：Google Apps、Dropbox、Salesforce、Cisco WebEx、Concur和GoToMeeting等
IaaS
Infrastructure as a Service。云基础架构服务称为基础架构即服务（IaaS），由高度可扩展和自动化的计算资源组成。 IaaS是完全自助服务，用于访问和监控计算、网络，存储和其他服务等内容，它允许企业按需求和需要购买资源，而不必购买全部硬件。
优点：
是最灵活的云计算模型
轻松实现存储、网络，服务器和处理能力的自动部署
可以根据消耗量购买硬件
使客户能够完全控制其基础架构
可以根据需要购买资源
高度可扩展
IaaS例子：DigitalOcean，Linode，Rackspace，AWS，Cisco Metapod，Microsoft Azure，Google Compute Engine（GCE）
FaaS
Function as a Service。这个概念和最近的无服务架构(Serverless Architecture)联系在一起。Serverless并不是说没有服务器参与，它通过将复杂的服务器架构透明化，使开发者专注于“要做什么”，从而强调了减少开发者对服务器等计算资源的关注、工作粒度从服务器切换到任务的思想。
这个概念还属于早期阶段，和微服务的架构模式还是有区别的，有人说是下一代微服务模型，也有人说是炒作，这里只看看概念，了解了解。
Serverless可以看作是比微服务架构更细粒度的架构模式，即FaaS，Lambda也是FaaS的典型代表，它允许用户仅仅上传代码而无需提供和管理服务器，由它负责代码的执行、高可用扩展，支持从别的AWS服务或其他Web应用直接调用等。
特点：
FaaS里的应用逻辑单元都可以看作是一个函数，开发人员只关注如何实现这些逻辑，而不用提前考虑性能优化，让工作聚焦在这个函数里，而非应用整体。
FaaS是无状态的，天生满足云原生(Cloud Native App)应用该满足的12因子(12 Factors)中对状态的要求。
FaaS的函数应当可以快速启动执行，并拥有短暂的生命周期。函数在有限的时间里启动并处理任务，并在返回执行结果后终止。如果它执行时间超过了某个阈值，也应该被终止。
FaaS函数启动延时受很多因素的干扰。以AWS Lambda为例，如果采用了JS或Python实现了函数，它的启动时间一般不会超过10~100毫秒。但如果是实现在JVM上的函数，当遇到突发的大流量或者调用间隔过长的情况，启动时间会显著变长。
FaaS需要借助于API Gateway将请求的路由和对应的处理函数进行映射，并将响应结果代理返回给调用方。
假如说我们由这样的一个架构：
我们可以通过将单体后端应用进行拆分得到如下结构：
这样做的优点有下面几点：
减少开支。通过购买共享的基础设施，同时减少了花费在运维上的人力成本，最终减少了开支。
减轻负担。不再需要重复造轮子，需要什么功能直接集成调用即可，也无需考虑整体的性能，只专注于业务代码的实现。
易于扩展。云上提供了自动的弹性扩展，用了多少计算资源，就购买多少，完全按需付费。
简化管理。自动化的弹性扩展、减少了打包和部署的复杂度、可以快速推向市场，这些都让管理变得简单高效。
环保计算。即使在云的环境上，仍习惯于购买多余的服务器，最终导致空闲。Serverless杜绝了这种情况。
关于微服务的前生今世
Who
微服务思想的提出者是Martin Fowler，他对微服务的定义如下：
The term "Microservice Architecture" has sprung up over the last few years to describe a particular way of designing software applications as suites of independently deployable services. While there is no precise definition of this architectural style, there are certain common characteristics around organization around business capability, automated deployment, intelligence in the endpoints, and decentralized control of languages and data.
可以浏览微服务作者Martin Fowler的网站进行学习：https://www.martinfowler.com/articles/microservices.html
What & Where
我也是很有巧的在图书馆有借到一本《Docker 微服务架构实战》，本来是打算给项目使用，顺便复习复习docker，没成想成了我的第一本微服务指导书了:joy:。这本书是2018年11月出的，也算比较新了，作者在序言里讲解的到位，这里分享给大家。
序言
......
从单体架构到分布式服务架构，到SOA架构，再到微服务架构以及最新的服务网格，架构演进的步伐在业务爆发式增长的背景下从未停滞过......
......
微服务的核心思想就是将整个业务系统拆分为相对独立的业务模块，并强调各个微服务都可以独立开发、独立测试、独立部署、独立运行、独立运维。这种松耦合的灵活的特性正是目前业界所有人所盼望的，因此微服务架构在比较短的时间内便在很多互联网企业被落地实践，成为解决复杂应用的一把利器。比微服务更进一步的网络网格(Service Mesh)更是将传统服务治理框架中的服务注册、服务发现、服务熔断、服务降级、服务限流这些和业务无关的东西抽离了出来，下沉为底层服务，让研发的中心更集中在业务逻辑的实现上。而容器技术再次过程中发挥了“推波助澜”的作用，加速了微服务的产业化步伐。
什么是微服务？我的的理解即为将一个复杂的、大块的应用程序拆分为多个小的应用程序，并对它们进行管理，所产生的一个生态圈。当然引用一下蒋彪老师的更严格的话：在团队人数井喷，产品迭代周期太快，系统中的技术负债过剩导致不能将鸡蛋放到同一个摇摇欲坠的篮子，投资人对产品功能特性提出夸张、多变要求的大背景下，在投资人、经理层、研发人员、测试人员、运维人员等各个利益相关者的逼迫下，被迫地将系统从开发、扩展、易维护等维度进行的拆分。
或者我们举一个例子，你想要写一个python应用，他有诸多模块如在线API的使用，本地数据的处理，邮件的收发，网页的展示等等，有不同维度的功能集合，并且你都写到了一个py文件中，这个文件达到了几千行的数量，这样的代码如果加之没有规范、没有文档注释说明等，可能就你一个人能维护了。
于是你改变了思路，你以不同功能维度作为分类标准，将这个py文件分为了web.py、api.py、data.py等等，这样每一个的代码量大大减小，并且业务逻辑更加集中，并且可以独立开发、独立测试、独立部署、独立运行等等，这就好比微服务的拆分。
但是你发现偶尔会有一两个模块因为如网络延迟原因造成了整体进度的缓慢甚至因为抛出了异常导致了整个项目的终止，所以你需要对这些特殊情况进行处理，你想到了使用try..catch对异常点进行处理，这就好比你在治理你的项目"生态"。
如果觉得我的描述不够清晰，可以看知乎的例子：https://www.zhihu.com/question/65502802
When
微服务是从早期的CORBA、COM+等技术，到后来的SOA以及一度流行的RESTful架构，是一种一脉相承的分布式计算思想。——《Docker 微服务架构实战》
下面对早期的一些分布式技术的实现进行了解。
CORBA
1989年，CORBA由OMG组织（Unisys、Sun、Cannon、Hewlett-Packard、Philips等）提出，提供了一种跨平台、跨语言的分布式协同规划。
它的核心是ORB（Object Request Broker），用于对象之间的互通信。但是CORBA的问题在于他的通信协议过于重量级；服务之间的契约依赖于代码共享的暴露和通信；部署过程复杂。
DCOM
DCOM是微软为了对抗CORBA和RMI所开发的分布式计算框架，通过依赖COM运行库来达到分布式环境下互相访问、互相协同的作用，具有与语言无关、位置的独立、优化网络、负载均衡、支持容错性的特点。
RMI
RMI是Java 1.1推出的分布式计算协议，RM都很熟悉了，这里不做解释，只说说它的特点：面向对象、可移动属性、分层的设计方式、安全性高、便于编写和使用、可连接现有/原有的系统、编写一次处处运行、分布式垃圾收集、并行计算。
RMI不支持跨语言开发，但是RMI的思想直到今天的Dubbo都有借鉴。
SOA
微服务是轻量级的SOA，SOA是重量级的微服务。 ——《Docker 微服务架构实战》
SOA的时间线在2008年。SOA（Service-Oriented Architecture，面向服务的体系结构）是一种思想、方法论、分布式的服务架构。
在实现服务自治这方面，SOA主要依赖两种消息机制来解决分布式的协同问题：
- 基于请求响应的Web契约协议(包括基于HTTP和XML的SOAP、服务接口描述语言WSDL，服务查找接口UDDI)
- 基于实践EDA的企业服务总线ESB(用于设计和实现软件应用之间交互和通信的体系架构模型)
举个常用的例子，RabbitMQ就是ESB的实现，除此之外还有RocketMQ、MuleMQ。而一些如WSDL、Hession、SOAP则是Web契约协议的实现。
那么SOA和微服务的区别在哪里？
| 区别 | SOA和微服务 |
|---|---|
| 通信协议 | 微服务使用RESTful的API来传输报文，而非使用四层网络模型协议之上传输序列化对象 |
| 最细颗粒 | SOA最细颗粒为组件；微服务较SOA拆分更细 |
微服务时代的技术梦想是将应用拆分成一个个不依赖于任何服务器和数据模型的全栈应用，使其可以通过自动化方式独立部署，每个服务可以运行在自己的进程或Docker容器中，通过轻量级的通信机制联系，能够基于业务能力快速构建、动态扩容、实现集中化管理的系统架构。这是从CORBA到SOA到微服务时代的技术梦想。——《Docker 微服务架构实战》
Why
从学术角度来说，微服务是为了解决scale cube（扩展立方）上的三维扩展问题，以及分布式动态伸缩架构中的问题而提出的思想。——《Docker 微服务架构实战》。
scale cube的扩展问题实际为如何在三维空间中将一个立方体的体积进行扩展，那当然是三个维度了：x、y、z。
X轴扩展
即一个搬运工不够，我请了10个总可以吧？如果一个任务总量为10，2个搬运工搬运的话，每一个人的负载量为5，但是如果我叫了10个搬运工，那么每个搬运工的负载量就是1，显然是轻松多了。
X轴扩展，一般也被称为应用的横向扩展或者水平扩展。——《Docker 微服务架构实战》。
但是缺点是10个搬运工会导致你的钱包开销变大，每一个搬运工会潜在的访问所有的数据，造成缓存量的增大。虽然保证了这个服务的高可用性，却没有解决单体服务开发和维护复杂性的问题
Y轴扩展
水平扩展的原理是将同一个服务进行拷贝达到高可用的效果，而Y轴扩展通过将应用划分为多个层次的服务来进行拆分服务，即2个搬运工搬运10个物资，一个人搬一半路程，另一个人接手搬到目的地。
Y轴扩展有两种方式：
- 使用动词分解：即将支付部分拆为支付服务、交易部分拆为交易服务、登录部分拆为登录服务。
- 使用名词分解：一个系统中由客户、厂家、银行、第三方监督组成，那么各自成一个服务。
实际环境中采用动词名词混合的拆解方式。
Y轴扩展，一般也称为业务扩展，或者垂直扩展。——《Docker 微服务架构实战》。
Y轴扩展的缺点是服务只有一份，即那两个搬运工的负载量还是5，累死一个就没了，没有考虑在分区失效下的高可用问题，即忽略了CAP理论中的分区容错性(partition tolerance)。
CAP定理，C代表数据一致性，A代表服务可用性，P代表服务对网络分区故障的容错性。这三个特性在任何分布式系统中都不能同时满足，最多只能满足两个。——《Docker 微服务架构实战》。
Z轴扩展
如果水平扩展时对应用的横向扩展，垂直扩展是对应用的纵向切分，那么Z轴扩展就是对不同数据维护的分区拆分。——《Docker 微服务架构实战》。
Z轴扩展中，多个服务器上运行相同的代码，当用户进行请求时，会对用户的类型进行区分，比如你是百度云大会员:happy:，你的下载速度就噌噌噌，你是普通会员....。
Z轴扩展类似于X轴扩展，最大的区别就是数据集的划分，假设5个搬运工，由一个带状态的分发器进行管理，来了任务，该分发器符将请求路由到合适的搬运工那里，谁不累就可以接活。这一个分发器其实就是API网关了。
参考学习
http://liubao68.gitee.io/servicecomb-java-chassis-doc/java-chassis/zh_CN/toc/
https://www.bmc.com/blogs/saas-vs-paas-vs-iaas-whats-the-difference-and-how-to-choose/
http://www.uml.org.cn/zjjs/202001023.asp
