第一周

云计算

什么是云计算

云计算是一种模式，该模式允许用户通过无所不在的、便捷的、按需获得的网络，接入到一个可动态配置的共享计算资源池（其中包括网络设备、服务器、存储、应用以及业务），并且以最小的管理代价或业务交互复杂度即可实现这些可配置计算资源的快速发放与发布。

Saas软件即服务面临的挑战和它的适用性

挑战一：转换成本高。解决方案是提升服务质量，增强客户满意度。

挑战二：有限的灵活性。解决方案是提供应用程序交换平台，提供可定制化服务。

挑战三：安全性和隐私性。解决方案是尽可能谨慎并更加专业化。

SaaS的适用性：

1、企业软件应用

• 执行业务功能
• 组织内部和外部信息
• 在内部和外部用户之间共享数据
• 适用于Saas模型的最标准类型的软件
• 示例：Saleforce.com CRM应用 Siebel On-demand 程序

2、单用户软件应用

• 组织个人信息
• 在用户自己的本地计算机上运行
• 一次只服务于一个用户
• 不适用于Saas模型
  • 数据安全问题
  • 网络性能问题
• 示例：Microsoft办公套件

3、基础设施软件

• 作为大多数其他企业软件应用的基础
• 不适用于Saas模型
  • 需要在本地安装
  • 形成运行其他应用程序的基础
• 示例：Window XP、Oracle数据库

4、嵌入式软件

• 嵌入式系统软件组件
• 支持硬件设备的功能
• 不适用于Saas模型
  • 嵌入式软硬件结合在一起，密不可分。
• 示例：嵌入ATM机、手机、路由器、医疗设备等的软件

 

PaaS的概念

PaaS（平台即服务）是一个计算平台，它使得用户能够快速、方便地创建web应用，并且无需担心维护下层软件。其基本特征包括：在相同的集成开发环境中用来开发、测试、部署、托管和维护的应用;基于web的用户界面来创建工具，可用于创建、修改、测试和部署不同的UI场景；多租户架构，可使多个并发用户使用相同的开发应用；内置部署软件的可扩展性，包括负载均衡和故障转移；通过公共标准集成web服务和数据库；支持开发团队协作，包括一些PaaS解决方案以及项目规划、沟通工具等。

国内外著名PaaS提供者包括Google App Engine、Microsoft Azure、百度云等

IaaS的概念

IaaS(基础设施即服务)以服务模式提供计算、存储、网络等基础设施资源给用户。传统方式下企业需要去买物理服务器、存储等硬件来承载本地应用，让企业业务运行起来。通过IaaS，企业可将硬件外包给IaaS供应商，供应商会提供可支撑企业应用的服务器，存储和网络硬件及虚拟化软件，对上层业务提供虚拟机或其他基础设施资源。主流的IaaS供应商包括Amazon，Microsoft，VMWare，阿里、腾讯等

AMI（Amazon Machine Images）

AMI是一种使用亚马逊云计算服务时创建的机器镜像，机器镜像中包括操作系统、应用程序和配置设置。

通过AMI可以运行多个实例，这些实例是AMI的副本，每个实例类型提供不同的计算和内存设施。

Hadoop

Hadoop是一个由apache基金会所开发的分布式系统基础架构，用户可以在不了解分布式底层细节的情况下，开发分布式程序，Hadoop的使用和流行使人们可以充分利用集群的能力进行高速运算和存储。

Hadoop各组件：

HBase（分布式列存数据库）、Zookeeper（分布式协作服务）、Sqoop（数据同步工具）、Hive（数据仓库工具）、Pig（数据流系统）、Mahout（数据挖掘算法库）、Flume（日志收集工具）、Yarn（资源管理器）

DevOps介绍

DevOps 是一个完整的面向IT运维的工作流，以 IT 自动化以及持续集成（CI）、持续部署（CD）为基础，来优化程式开发、测试、系统运维等所有环节。

SOA面向服务架构相关概念，微服务概念

面向服务的架构（SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）进行拆分，并通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。

微服务是指开发一个单个小型的但有业务功能的服务，每个服务都有自己的处理和轻量通讯机制，可以部署在单个或多个服务器上。微服务也指一种种松耦合的、有一定的有界上下文的面向服务架构。也就是说，如果每个服务都要同时修改，那么它们就不是微服务，因为它们紧耦合在一起；如果你需要掌握一个服务太多的上下文场景使用条件，那么它就是一个有上下文边界的服务，这个定义来自DDD领域驱动设计。

相对于单体架构和SOA，它的主要特点是组件化、松耦合、自治、去中心化，体现在以下几个方面：

• 一组小的服务 

• 独立部署运行和扩展 

• 独立开发和演化 

• 独立团队和自治 

第二周

敏捷

敏捷是一组用于软件产品开发的实践、价值和原则。

敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。它不是一门技术，它是一种开发方法，也就是一种软件开发的流程，它会指导我们用规定的环节去一步一步完成项目的开发；而这种开发方式的主要驱动核心是人；它采用的是迭代式开发。

 

为什么要用敏捷开发：敏捷使软件产品更好地响应客户需求，同时可以有效节省精力和资金。

传统的开发模型可能会增加客户的成本，原因如下：

1、新技术不断引进。

2、新玩家进入市场，

3、增加了新的要求

4、“小即美”

5、倾听顾客的需求，能降低被更小、更灵活的竞争对手击败的风险。

6、任何有助于降低维护成本的东西都有助于项目实现

 

敏捷开发和传统开发对比：

敏捷软件开发与传统开发方法相比具有很大的不同，其特点是适应性而不是预测性，强调沟通和反馈，开发团队不仅包括开发人员，还包括管理人员和客户。它鼓励团队成员的相互交流通过反馈机制尽早纠正软件中的错误，提高开发效率，同时为需求的调整提供更多机会，保证软件向正确的方向发展。

传统软件开发如瀑布模型强调预见性，严格遵循计划、分析、设计、编码、测试和维护等几个阶段。瀑布模型开发各阶段间具有严格的顺序性和依赖性，必须等到前一阶段的工作结束后才能开始下一阶段的工作，前一阶段的输出文档是后一阶段的输入文档，只有前一阶段的输出文档完全正确，后一阶段才能获得正确的结果。

 

敏捷开发的原则：

1、最优先考虑的是通过早期和连续交付有价值的软件来满足客户。

2、拥抱变化。敏捷过程利用变化来获得竞争优势。

3、频繁地交付工作，从几周到几个月，优先用更短的交付时间。

4、同一个项目的业务人员和开发人员必须在一起工作。

5、围绕有能力的个人建立项目。给他们需要的环境和支持，信任他们完成工作。

6、向开发团队传递信息最有效的方法是面对面的交谈。

7、工作软件是进度的主要度量。

8、敏捷过程促进可持续发展。赞助商、开发人员和用户应该能够无限期地保持恒定的步伐。

9、持续关注技术的卓越性和良好的设计可以提高敏捷性。

10、简洁是必不可少的。

11、组建团队实现最好的架构、需求和设计。

12、每隔一段时间，团队要思考如何变得更加有效，然后相应地进行调整。

 

敏捷方法：scrum

scrum是一种敏捷开发流程，在scrum流程中包含三大角色：

产品负责人（Product Owner）

主要负责确定产品的功能和达到要求的标准，指定软件的发布日期和交付的内容，同时有权力接受或拒绝开发团队的工作成果。

流程管理员（Scrum Master）

主要负责整个Scrum流程在项目中的顺利实施和进行，以及清除挡在客户和开发工作之间的沟通障碍，使得客户可以直接驱动开发。

开发团队（Scrum Team）

主要负责软件产品在Scrum规定流程下进行开发工作，人数控制在5~10人左右，每个成员可能负责不同的技术方面，但要求每成员必须要有很强的自我管理能力，同时具有一定的表达能力；成员可以采用任何工作方式，只要能达到Sprint的目标。

如何进行scrum开发：

1、我们首先需要确定一个Product Backlog（按优先顺序排列的一个产品需求列表），这个是由Product Owner 负责的；

2、Scrum Team根据Product Backlog列表，做工作量的预估和安排；

3、有了Product Backlog列表，我们需要通过 Sprint Planning Meeting（Sprint计划会议） 来从中挑选出一个Story作为本次迭代完成的目标，这个目标的时间周期是1~4个星期，然后把这个Story进行细化，形成一个Sprint Backlog；

4、Sprint Backlog是由Scrum Team去完成的，每个成员根据Sprint Backlog再细化成更小的任务（细到每个任务的工作量在2天内能完成）；

5、在Scrum Team完成计划会议上选出的Sprint Backlog过程中，需要进行 Daily Scrum Meeting（每日站立会议），每次会议控制在15分钟左右，每个人都必须发言，并且要向所有成员当面汇报你昨天完成了什么，并且向所有成员承诺你今天要完成什么，同时遇到不能解决的问题也可以提出，每个人回答完成后，要走到黑板前更新自己的 Sprint burn down（Sprint燃尽图）；

6、做到每日集成，也就是每天都要有一个可以成功编译、并且可以演示的版本；很多人可能还没有用过自动化的每日集成，其实TFS就有这个功能，它可以支持每次有成员进行签入操作的时候，在服务器上自动获取最新版本，然后在服务器中编译，如果通过则马上再执行单元测试代码，如果也全部通过，则将该版本发布，这时一次正式的签入操作才保存到TFS中，中间有任何失败，都会用邮件通知项目管理人员；

7、当一个Story完成，也就是Sprint Backlog被完成，也就表示一次Sprint完成，这时，我们要进行 Srpint Review Meeting（演示会议），也称为评审会议，产品负责人和客户都要参加（最好本公司老板也参加），每一个Scrum Team的成员都要向他们演示自己完成的软件产品（这个会议非常重要，一定不能取消）；

8、最后就是 Sprint Retrospective Meeting（回顾会议），也称为总结会议，以轮流发言方式进行，每个人都要发言，总结并讨论改进的地方，放入下一轮Sprint的产品需求中；

敏捷估算

计划扑克玩法

1.发牌 
2.拎出一个要估算的功能，PM解释要求 
3.开发人员根据功能给出自己的估算值，用牌上 的最接近的数字代替，出牌背面朝上（每次一张） 
4.大家同时翻转牌，差距过大的人给出自己的想法 
5.大家根据刚刚的发言再出牌和翻转，直到达成一致，该功能的估算结束 
6.重复2~5直至团队资源耗尽。
 

第三周

scrum

scrum中的迭代方式

1、迭代计划——为一次迭代创建一个计划

选择下一个要交付的内容（按优先级选择），定义和估计任务，协商交付产品的范围

2、迭代执行——实现计划中的项目

处理需求、设计、代码、集成/构建，并测试计划中需要的模块

3、交付迭代的结果——给出demo

步骤1-3将根据发布计划多次执行

每个周期是一个固定长度的时间盒：

总是按计划结束每次迭代，即使它不是完整的

（不要说——“我们可以在另外两天内完成这次迭代的所有工作”）。只需交付并运行下一次迭代计划会议。

团队学会了做出好的短期估计——因此，随着时间的推移，大多数迭代都会如期交付。

scrum角色

scrum小组

scrum板

待办事项

敏捷使用产品Backlog来管理需求，产品Backlog是一个需求的清单，按照需求的商业价值排序， 高优先级的需求在Backlog的最上层。产品Backlog是一个渐进明细的清单，它有4个主要特点，称之为DEEP：

• Detailed 合适的详细程度，高优先级需求更加明细，低优先级的需求粒度更大
• Emergent 涌现式的，需求是慢慢涌现出来的，渐进明细的
• Estimated 经过估算的
• Prioritized/ Ordered 根据商业价值排好顺序的

在产品Backlog中，需求的主要表现形式是用户故事。用户故事是从用户的角度对需求的简短描述。用户故事是将团队的焦点从描述、编写功能需求转移到讨论需求的最佳方式。

用户故事是从用户的角度来描述用户渴望得到的功能。一个好的用户故事包括三个要素：

• 角色：谁要使用这个功能。
• 活动：需要完成什么样的功能。
• 商业价值：为什么需要这个功能，这个功能带来什么样的价值。

作为一个<角色>, 我想要<活动>, 以便于<商业价值>。
比如：作为一个网站的普通会员，我期望在我下订单后，未发货之前可以取消订单，这样对我来说更灵活。

scrum管理工具

https://www.leangoo.com/kanban/board_list

第四周

软件系统架构演变

1.1 单一应用架构

当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。此时，用于简化增删改查工作量的数据访问框架(ORM)是关键。

1.2 垂直应用架构

当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率。此时，用于加速前端页面开发的Web框架(MVC)是关键。

1.3 分布式服务架构

当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。此时，用于提高业务复用及整合的分布式服务框架(RPC)是关键。

1.4 流动计算架构

当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。此时，用于提高机器利用率的资源调度和治理中心(SOA)是关键。

 

一、微服务介绍

1. 什么是微服务

      微服务得从两个方面去理解，什么是”微”、什么是”服务”， 微 狭义来讲就是体积小、著名的”2 pizza 团队”很好的诠释了这一解释（2 pizza 团队最早是亚马逊 CEO Bezos提出来的，意思是说单个服务的设计，所有参与人从设计、开发、测试、运维所有人加起来 只需要2个披萨就够了 ）。 而所谓服务，一定要区别于系统，服务一个或者一组相对较小且独立的功能单元，是用户可以感知最小功能集。

2. 微服务由来

    微服务最早由Martin Fowler与James Lewis于2014年共同提出，微服务架构风格是一种使用一套小服务来开发单个应用的方式途径，每个服务运行在自己的进程中，并使用轻量级机制通信，通常是HTTP API，这些服务基于业务能力构建，并能够通过自动化部署机制来独立部署，这些服务使用不同的编程语言实现，以及不同数据存储技术，并保持最低限度的集中式管理。

3. 为什么需要微服务/span>

        在传统的IT行业软件大多都是各种独立系统的堆砌，这些系统的问题总结来说就是扩展性差，可靠性不高，维护成本高。到后面引入了SOA服务化，但是，由于 SOA 早期均使用了总线模式，这种总线模式是与某种技术栈强绑定的，比如：J2EE。这导致很多企业的遗留系统很难对接，切换时间太长，成本太高，新系统稳定性的收敛也需要一些时间。最终 SOA 看起来很美，但却成为了企业级奢侈品，中小公司都望而生畏。

3.1 最期的单体架构带来的问题

单体架构在规模比较小的情况下工作情况良好，但是随着系统规模的扩大，它暴露出来的问题也越来越多，主要有以下几点：

1.复杂性逐渐变高

比如有的项目有几十万行代码，各个模块之间区别比较模糊，逻辑比较混乱，代码越多复杂性越高，越难解决遇到的问题。

2.技术债务逐渐上升

公司的人员流动是再正常不过的事情，有的员工在离职之前，疏于代码质量的自我管束，导致留下来很多坑，由于单体项目代码量庞大的惊人，留下的坑很难被发觉，这就给新来的员工带来很大的烦恼，人员流动越大所留下的坑越多，也就是所谓的技术债务越来越多。

3.部署速度逐渐变慢

这个就很好理解了，单体架构模块非常多，代码量非常庞大，导致部署项目所花费的时间越来越多，曾经有的项目启动就要一二十分钟，这是多么恐怖的事情啊，启动几次项目一天的时间就过去了，留给开发者开发的时间就非常少了。

4.阻碍技术创新

比如以前的某个项目使用struts2写的，由于各个模块之间有着千丝万缕的联系，代码量大，逻辑不够清楚，如果现在想用spring mvc来重构这个项目将是非常困难的，付出的成本将非常大，所以更多的时候公司不得不硬着头皮继续使用老的struts架构，这就阻碍了技术的创新。

5.无法按需伸缩

比如说电影模块是CPU密集型的模块，而订单模块是IO密集型的模块，假如我们要提升订单模块的性能，比如加大内存、增加硬盘，但是由于所有的模块都在一个架构下，因此我们在扩展订单模块的性能时不得不考虑其它模块的因素，因为我们不能因为扩展某个模块的性能而损害其它模块的性能，从而无法按需进行伸缩。

3.2 微服务与单体架构区别

1、单体架构所有的模块全都耦合在一块，代码量大，维护困难，微服务每个模块就相当于一个单独的项目，代码量明显减少，遇到问题也相对来说比较好解决。

2、单体架构所有的模块都共用一个数据库，存储方式比较单一，微服务每个模块都可以使用不同的存储方式（比如有的用redis，有的用mysql等），数据库也是单个模块对应自己的数据库。

3、单体架构所有的模块开发所使用的技术一样，微服务每个模块都可以使用不同的开发技术，开发模式更灵活。

3.3 微服务与SOA区别

微服务，从本质意义上看，还是 SOA 架构。但内涵有所不同，微服务并不绑定某种特殊的技术，在一个微服务的系统中，可以有 Java 编写的服务，也可以有 Python编写的服务，他们是靠Restful架构风格统一成一个系统的。所以微服务本身与具体技术实现无关，扩展性强。

4. 微服务本质

1、微服务，关键其实不仅仅是微服务本身，而是系统要提供一套基础的架构，这种架构使得微服务可以独立的部署、运行、升级，不仅如此，这个系统架构还让微服务与微服务之间在结构上“松耦合”，而在功能上则表现为一个统一的整体。这种所谓的“统一的整体”表现出来的是统一风格的界面，统一的权限管理，统一的安全策略，统一的上线过程，统一的日志和审计方法，统一的调度方式，统一的访问入口等等。

2、微服务的目的是有效的拆分应用，实现敏捷开发和部署 。

3、微服务提倡的理念团队间应该是 inter-operate, not integrate 。inter-operate是定义好系统的边界和接口，在一个团队内全栈，让团队自治，原因就是因为如果团队按照这样的方式组建，将沟通的成本维持在系统内部，每个子系统就会更加内聚，彼此的依赖耦合能变弱，跨系统的沟通成本也就能降低。

5. 什么样的项目适合微服务

   微服务可以按照业务功能本身的独立性来划分，如果系统提供的业务是非常底层的，如：操作系统内核、存储系统、网络系统、数据库系统等等，这类系统都偏底层，功能和功能之间有着紧密的配合关系，如果强制拆分为较小的服务单元，会让集成工作量急剧上升，并且这种人为的切割无法带来业务上的真正的隔离，所以无法做到独立部署和运行，也就不适合做成微服务了。

能不能做成微服务，取决于四个要素：

小：微服务体积小，2 pizza 团队。

独：能够独立的部署和运行。

轻：使用轻量级的通信机制和架构。

松：为服务之间是松耦合的。

1. 微服务折分与设计

1、从单体式结构转向微服务架构中会持续碰到服务边界划分的问题：比如，我们有user 服务来提供用户的基础信息，那么用户的头像和图片等是应该单独划分为一个新的service更好还是应该合并到user服务里呢果服务的粒度划分的过粗，那就回到了单体式的老路；如果过细，那服务间调用的开销就变得不可忽视了，管理难度也会指数级增加。目前为止还没有一个可以称之为服务边界划分的标准，只能根据不同的业务系统加以调节

2、拆分的大原则是当一块业务不依赖或极少依赖其它服务，有独立的业务语义，为超过2个的其他服务或客户端提供数据，那么它就应该被拆分成一个独立的服务模块。

6.1 微服务设计原则

单一职责原则

意思是每个微服务只需要实现自己的业务逻辑就可以了，比如订单管理模块，它只需要处理订单的业务逻辑就可以了，其它的不必考虑。

服务自治原则

意思是每个微服务从开发、测试、运维等都是独立的，包括存储的数据库也都是独立的，自己就有一套完整的流程，我们完全可以把它当成一个项目来对待。不必依赖于其它模块。

轻量级通信原则

首先是通信的语言非常的轻量，第二，该通信方式需要是跨语言、跨平台的，之所以要跨平台、跨语言就是为了让每个微服务都有足够的独立性，可以不受技术的钳制。

接口明确原则

由于微服务之间可能存在着调用关系，为了尽量避免以后由于某个微服务的接口变化而导致其它微服务都做调整，在设计之初就要考虑到所有情况，让接口尽量做的更通用，更灵活，从而尽量避免其它模块也做调整。

7. 微服务优势与缺点

7.1 特性

1、每个微服务可独立运行在自己的进程里；

2、一系列独立运行的微服务共同构建起了整个系统；

3、每个服务为独立的业务开发，一个微服务一般完成某个特定的功能，比如：订单管理，用户管理等；

4、微服务之间通过一些轻量级的通信机制进行通信，例如通过REST API或者RPC的方式进行调用。

7.2 特点

易于开发和维护

由于微服务单个模块就相当于一个项目，开发这个模块我们就只需关心这个模块的逻辑即可，代码量和逻辑复杂度都会降低，从而易于开发和维护。

启动较快

这是相对单个微服务来讲的，相比于启动单体架构的整个项目，启动某个模块的服务速度明显是要快很多的。

局部修改容易部署

在开发中发现了一个问题，如果是单体架构的话，我们就需要重新发布并启动整个项目，非常耗时间，但是微服务则不同，哪个模块出现了bug我们只需要解决那个模块的bug就可以了，解决完bug之后，我们只需要重启这个模块的服务即可，部署相对简单，不必重启整个项目从而大大节约时间。

技术栈不受限

比如订单微服务和电影微服务原来都是用java写的，现在我们想把电影微服务改成nodeJs技术，这是完全可以的，而且由于所关注的只是电影的逻辑而已，因此技术更换的成本也就会少很多。

按需伸缩

我们上面说了单体架构在想扩展某个模块的性能时不得不考虑到其它模块的性能会不会受影响，对于我们微服务来讲，完全不是问题，电影模块通过什么方式来提升性能不必考虑其它模块的情况。

7.3 缺点

运维要求较高

对于单体架构来讲，我们只需要维护好这一个项目就可以了，但是对于微服务架构来讲，由于项目是由多个微服务构成的，每个模块出现问题都会造成整个项目运行出现异常，想要知道是哪个模块造成的问题往往是不容易的，因为我们无法一步一步通过debug的方式来跟踪，这就对运维人员提出了很高的要求。

分布式的复杂性

对于单体架构来讲，我们可以不使用分布式，但是对于微服务架构来说，分布式几乎是必会用的技术，由于分布式本身的复杂性，导致微服务架构也变得复杂起来。

接口调整成本高

比如，用户微服务是要被订单微服务和电影微服务所调用的，一旦用户微服务的接口发生大的变动，那么所有依赖它的微服务都要做相应的调整，由于微服务可能非常多，那么调整接口所造成的成本将会明显提高。

重复劳动

对于单体架构来讲，如果某段业务被多个模块所共同使用，我们便可以抽象成一个工具类，被所有模块直接调用，但是微服务却无法这样做，因为这个微服务的工具类是不能被其它微服务所直接调用的，从而我们便不得不在每个微服务上都建这么一个工具类，从而导致代码的重复。

8. 微服务开发框架

目前微服务的开发框架，最常用的有以下四个：

Spring Cloud：http://projects.spring.io/spring-cloud（现在非常流行的微服务架构）

Dubbo：http：//dubbo.io

Dropwizard：http://www.dropwizard.io （关注单个微服务的开发）

Consul、etcd&etc.（微服务的模块）

无论是Dubbo还是Spring Cloud都只适用于特定的应用场景和开发环境，它们的设计目的并不是为了支持通用性和多语言性。并且它们只是Dev层的框架，缺少DevOps的整体解决方案（这正是微服务架构需要关注的）。而随之而来的便是Service Mesh的兴起。

 

9. Sprint cloud 和 Sprint boot区别

Spring Boot:

旨在简化创建产品级的Spring应用和服务，简化了配置文件，使用嵌入式web服务器，含有诸多开箱即用微服务功能，可以和spring cloud联合部署。

 Spring Cloud：

微服务工具包，为开发者提供了在分布式系统的配置管理、服务发现、断路器、智能路由、微代理、控制总线等开发工具包。

二、微服务实践先知

1. 客户端如何访问这些服务API Gateway）

传统的开发方式，所有的服务都是本地的，UI可以直接调用，现在按功能拆分成独立的服务，跑在独立的一般都在独立的虚拟机上的 Java进程了。客户端UI如何访问他的台有N个服务，前台就需要记住管理N个服务，一个服务下线/更新/升级，前台就要重新部署，这明显不服务我们 拆分的理念，特别当前台是移动应用的时候，通常业务变化的节奏更快。另外，N个小服务的调用也是一个不小的网络开销。还有一般微服务在系统内部，通常是无状态的，用户登录信息和权限管理最好有一个统一的地方维护管理（OAuth）。

所以，一般在后台N个服务和UI之间一般会一个代理或者叫API Gateway，他的作用包括

提供统一服务入口，让微服务对前台透明

聚合后台的服务，节省流量，提升性能

提供安全，过滤，流控等API管理功能

我的理解其实这个API Gateway可以有很多广义的实现办法，可以是一个软硬一体的盒子，也可以是一个简单的MVC框架，甚至是一个Node.js的服务端。他们最重要的作用是为前台（通常是移动应用）提供后台服务的聚合，提供一个统一的服务出口，解除他们之间的耦合，不过API Gateway也有可能成为单点故障点或者性能的瓶颈。

2. 服务之间如何通信服务调用）

因为所有的微服务都是独立的Java进程跑在独立的虚拟机上，所以服务间的通行就是IPC（inter process communication），已经有很多成熟的方案。现在基本最通用的有两种方式。

REST（JAX-RS，Spring Boot）

RPC（Thrift, Dubbo）

异步消息调用(Kafka, Notify)

一般同步调用比较简单，一致性强，但是容易出调用问题，性能体验上也会差些，特别是调用层次多的时候。RESTful和RPC的比较也是一个很有意 思的话题。一般REST基于HTTP，更容易实现，更容易被接受，服务端实现技术也更灵活些，各个语言都能支持，同时能跨客户端，对客户端没有特殊的要 求，只要封装了HTTP的SDK就能调用，所以相对使用的广一些。RPC也有自己的优点，传输协议更高效，安全更可控，特别在一个公司内部，如果有统一个的开发规范和统一的服务框架时，他的开发效率优势更明显些。就看各自的技术积累实际条件，自己的选择了。

而异步消息的方式在分布式系统中有特别广泛的应用，他既能减低调用服务之间的耦合，又能成为调用之间的缓冲，确保消息积压不会冲垮被调用方，同时能 保证调用方的服务体验，继续干自己该干的活，不至于被后台性能拖慢。不过需要付出的代价是一致性的减弱，需要接受数据最终一致性；还有就是后台服务一般要 实现幂等性，因为消息发送出于性能的考虑一般会有重复（保证消息的被收到且仅收到一次对性能是很大的考验）；最后就是必须引入一个独立的broker，如 果公司内部没有技术积累，对broker分布式管理也是一个很大的挑战。

3. 这么多服务怎么查找服务发现）

     在微服务架构中，一般每一个服务都是有多个拷贝，来做负载均衡。一个服务随时可能下线，也可能应对临时访问压力增加新的服务节点。服务之间如何相互 感知务如何管理就是服务发现的问题了。一般有两类做法，也各有优缺点。基本都是通过zookeeper等类似技术做服务注册信息的分布式管理。当 服务上线时，服务提供者将自己的服务信息注册到ZK（或类似框架），并通过心跳维持长链接，实时更新链接信息。服务调用者通过ZK寻址，根据可定制算法，找到一个服务，还可以将服务信息缓存在本地以提高性能。当服务下线时，ZK会发通知给服务客户端。

客户端做：优点是架构简单，扩展灵活，只对服务注册器依赖。缺点是客户端要维护所有调用服务的地址，有技术难度，一般大公司都有成熟的内部框架支持，比如Dubbo。 

服务端做：优点是简单，所有服务对于前台调用方透明，一般在小公司在云服务上部署的应用采用的比较多。

4. 服务挂了怎么办/span>

    分布式最大的特性就是网络是不可靠 的。通过微服务拆分能降低这个风险，不过如果没有特别的保障，结局肯定是噩梦。我们刚遇到一个线上故障就是一个很不起眼的SQL计数功能，在访问量上升 时，导致数据库load彪高，影响了所在应用的性能，从而影响所有调用这个应用服务的前台应用。所以当我们的系统是由一系列的服务调用链组成的时候，我们必须确保任一环节出问题都不至于影响整体链路。相应的手段有很多：

重试机制

限流

熔断机制

负载均衡

降级（本地缓存） 这些方法基本上都很明确通用，就不详细说明了。比如Netflix的Hystrix：https://github.com/Netflix/Hystrix

5. 微服务需要考虑的问题

API Gateway   服务间调用  服务发现  服务容错  服务部署   数据调用

6、微服务的开发生命周期

设计   开发   观察   依次循环

三、微服务重要部件

1. 微服务基本能力

2. 服务注册中心

    服务之间需要创建一种服务发现机制，用于帮助服务之间互相感知彼此的存在。服务启动时会将自身的服务信息注册到注册中心，并订阅自己需要消费的服务。

服务注册中心是服务发现的核心。它保存了各个可用服务实例的网络地址（IPAddress和Port）。服务注册中心必须要有高可用性和实时更新功能。上面提到的 Netflix Eureka 就是一个服务注册中心。它提供了服务注册和查询服务信息的REST API。服务通过使用POST请求注册自己的IPAddress和Port。每30秒发送一个PUT请求刷新注册信息。通过DELETE请求注销服务。客户端通过GET请求获取可用的服务实例信息。 Netflix的高可用（Netflix achieves high availability ）是通过在Amazon EC2运行多个实例来实现的,每一个Eureka服务都有一个弹性IP Address。当Eureka服务启动时，有DNS服务器动态的分配。Eureka客户端通过查询 DNS来获取Eureka的网络地址（IP Address和Por

来源：zsg97iori