spring cloud【进阶一】

微服务的概念：

是系统架构上的一种设计风格，主旨是将一个原本独立的系统拆分成多个小型服务，这些小型服务都在各自独立的进程中运行，服务之间通过基于Http的Restful API进行通信合作。被拆分成的每一个小型服务都围绕着系统中的某一项或一些耦合度较高的业务，每个模块专注单一业务功能对外提供服务，并可以独立编译及部署，功能进行构建，并且每个服务都维护者自身的数据存储，业务开发，自动化测试案例以及独立，同时各个各模块间互相通信彼此协作，组合为整体对外提供完整服务。

部署机制。由于有了轻量级的通信协作基础，所以这些微服务可以使用不同的语言来编写.

与单体系统的区别：

在以往传统的企业系统架构中，我们针对一个复杂的业务需求通常使用对象或业务类型构建一个单体项目。在项目中我们通常将需求分为三个主要部分：数据库，服务端处理，前端展现。在业务初期，由于所有的业务逻辑在一个应用中，开发，测试，部署都相对简单。但是随着企业的发展，系统为了应对不同的业务需求会不断的为该单体项目增加不同的业务模块：同时随着移动端设备的进步，前端展现模块已经不仅仅局限于web的形式，这对于系统后端向前端的支持需要更多的接口模块。单体应用由于面对的业务需求更为宽泛，不断扩大的需求会使得单体应用变得越来越大，单体应用的问题凸显出来。由于单体系统部署在一个进程内，往往我们修改了一个很小的功能，为了部署上线会影响其他功能的运行。维护成本太大，难以控制。
 

模块拆分，服务独立部署和扩展，由于每个服务都运行在自己的进程内，在部署上有了稳定的边界，这样每个服务的更细都不会影响其他服务的运行。由于是独立部署的，我们可以更准确的为每个服务评估性能容量，通过配合服务间的协作流程也可以更容易的发现系统的瓶颈位置，以及给出较为准确的系统级性能容量评估。

微服务出现的原因：随着用户需求个性化，产品生命周期变短，微服务架构是未来软件架构朝着灵活性，扩展性，伸缩性以及高可用性发展的必然方向。

实施微服务的挑战

1.运维的新挑战	在微服务架构中，运维人员需要维护的进程数量会大大增加。运维需要更多的自动化。
2.接口的一致性	拆分服务，但业务逻辑上的依赖不会消除，只是从单体应用中年的代码依赖变成了服务间的通信依赖。而当我们对原有接口进行了一些修改，那么交互方也需要协调这样的改变来进行发布，以保证接口的正确调用。我们需要更完善的接口和版本管理。
3.分布式的复杂性	由于拆分后的各个微服务都是独立部署并运行在各自的进程中，它们只能通过通信来进行协助，所以分布式环境的问题都将是微服务架构系统设计时需要考虑的重要因素，比如：网络延迟，分布式事务，异步消息等。
4. 服务组件化	组件，是一个独立更换和升级的单元。就像PC中的CPU，内存，显卡，硬盘一样，独立且可以更换升级而不影响其他单元。在微服务架构中，需要我们对服务进行组件化分解。服务，是一种进程外的组件，它通过HTTP等通信协议进行协作，而不是像传统组件那样以嵌入的方式协同工作。每一个服务都独立开发，部署，可以有效避免一个服务的修改引起整个系统的重新部署。
5.按业务组织团队	在实施微服务架构时，需要采用不同的团队分割方法。由于每一个微服务都是针对特定业务 的宽栈或全栈实现，既要负责数据的持久化存储，又要负责用户的接口定义等各种跨专业领域的智能。因此，面对大型项目的时候，对于微服务团队的拆分更加建议按业务线的方式进行拆分，一方面可以有效减少服务内部修改所产生的内耗；另外，团队边界可以变得更加清晰。
6.做产品的态度
7.智能端点和哑管道	在单体应用中，组件间直接通过函数调用的方式进行交互协作。而在微服务架构中，由于服务不在一个进程中，组件间的通信模式发生了改变，若仅仅将原来的进程内的方法调用改成RPC方法的调用，会导致微服务之间产生烦琐的通信，我们需要更粗粒度的通信协议。

  在微服务架构中，通常会使用以下两种服务调用方式

1	使用HTTP的restful api 或轻量级的消息发送协议，实现信