文章目录
前言
微服务是一种项目开发的设计思想。初期，我们往往将一个项目整体开发，整体部署。
这样的好处是在项目部署阶段是简单的，但是随着项目的体量的不断的增大，以及项目功能的复杂度越来越高，我们发现整体开发部署的风格已经不再适用了。例如：牵一发而动全身，并不是我们想要的。
微服务的诞生意在解决上述的问题，微服务的一个特点是分而治之，项目的规模大功能复杂，那么我们就可以根据部分的业务模块将其进行拆分小的独立的服务。既解决了牵一发而动全身，并不是我们想要的的问题，又更好的实现了业务模块之间的低耦合，业务模块内部的高内聚。
微服务架构还有一个技术外的好处，它使整个系统的分工更加明确，责任更加清晰，每个人专心负责为其他人提供更好的服务。
微服务的风格特点
接下来，我将从以下几个方面总结出微服务的风格特点。
1、组件化（Componentization ）与服务（Services）
了解过vue的朋友会知道，vue其实就是一个组件化编程，组件化编程的好处是我们可以随时进行组件的拔插，以实现快速的更换项目模块而且不会影响其他的模块。
微服务的一个特点就是将整体项目中的业务模块进行组件化（微服务），我们将每一个服务称之为组件而不是组件库，这是因为服务可以独立部署，如果有一个服务发生了改变，那么你只需要重新部署那个改变的服务即可。这听起来更像是一种"拔插式"的操作。
因为微服务是独立部署的，那么很多接口调度就变成了远程调度，远程调用比进制内调用更消耗资源，因此远程 API 需要粗粒度（coarser-grained），但这会比较难使用。如果你需要调整组件间的职责分配，当跨越进程边界时，这样做将会很难。
2、围绕业务功能的组织
设计一个系统时，将人员划分为 UI 团队，中间件团队，DBA 团队，那么相应地，软件系统也就会自然地被划分为 UI 界面，中间件系统，数据库。如下图：
对于微服务（microservice ）而言，根据微服务的划分方法不同，它倾向围绕业务功能的组织来分割服务。这些服务实现商业领域的软件，包括用户界面，持久化存储，任何的外部协作。
这就导致，负责一个服务（微服务）的团队虽具有的技术将是所有的【用户体验（user-experience）、数据库（database）和项目管理（project management）】。这对开发人员的要求提高了一个高度，我们可以通过一张图来进一步的解释。
3、产品不是项目
很多的开发团队都倾向与向运维组织方交付一个完成的项目（软件），然后解散构建软件的团队。但是对于微服务的支持者，这个是不被认可的。
正如亚马逊开发管理者所提倡的理念“你构建，你运维（you build, you run it）”。产品的理念，跟业务能力联系起来。不是着眼于完成一个项目（软件），而是有一个持续的关系，是如何能够帮助软件及其用户提升业务能力。
4、强化终端及弱化通道
微服务倾向于做如下的选择：强化终端及弱化通道。微服务的应用致力低耦合和高内聚：采用单独的业务逻辑，表现的更像经典Unix意义上的过滤器一样，接受请求、处理业务逻辑、返回响应。它们更喜欢简单的REST风格，而不是复杂的协议，如WS或者BPEL或者集中式框架。
所谓的"强化终端及弱化通道"，就是"低耦合，高内聚"的一种体现，因为本身服务（微服务）之间是通过远程API（接口）进行通信的，我们更希望"高内聚"，使得接口的调用高呢更加的纯粹——服务之间的通信。对应的业务尽可能的都是在独立的服务（微服务）中完成。
在整体工风格中，组件在进程内执行，进程间的消息通信通常通过调用方法或者回调函数。从整体式风格到微服务框架最大的问题在于通信方式的变更。从内存内部原始的调用变成远程调用，产生的大量的不可靠通信。因此，你需要把粗粒度的方法成更加细粒度的通信。
5、分散治理
集中治理的一种好处是在单一平台上进行标准化，有利于维护。但是我们更加倾向于采用适当的工具解决适当的问题。
当我们把整体式框架中的组件，拆分成不同的服务时，我们在构建它们时有更多的选择，例如：对于一些实时性能要求高的业务模块，那么我就可以使用C++进行开发，…
分散治理有他的绝对好处——物尽其用。对于一个问题而言，我们可以使用能适合它的工具来解决它。
6、分散数据管理
在传统的开发中，我们都是共用一个数据库。但是到了微服务阶段，我们更倾向于采用分散数据管理，所谓的分散数据库观管理其实就是对于每一个服务（微服务）而言，其都有它自己的数据库，我们可以通过下图进一步的了解单一数据管理与分散数据管理的区别与联系。
对于分散数据关系，要求开发者对于整个项目的业务需求更深的了解。但是对于不同得我服务（微服务）之间肯定会有数据库上述交互，例如：数据的同步、数据的一至性问题…。通常会通过事务来解决这个问题。
使用事务是因为它能够帮助处理一至性问题，但对时间的消耗是严重的，这给跨服务操作带来难题。分布式事务非常难以实施，因此微服务架构强调服务间事务的协调，并清楚的认识一致性只能是最终一致性以及通过补偿运算处理问题。
选择处理不一致问题对于开发团队来说是新的挑战，但是也是一个常见的业务实践模式。通常业务上允许一定的不一致以满足快速响应的需求，但同时也采用一些恢复的进程来处理这种错误。当业务上处理强一致性消耗比处理错误的消耗少时，这种付出是值的的。
7、基础设施自动化
许多使用微服务架构的产品或者系统，它们的团队拥有丰富的持续部署（CD）以及它的前任持续集成的经验。团队使用这种方式构建软件致使更广泛的依赖基础设施自动化技术。下图说明这种构建的流程：
另一个方面，我们发现使用微服务的团队更加依赖于基础设施的自动化。对于整体架构的部署与微服务架构的部署，我们通过下图进一步的了解。
8、容错性设计
使用服务作为组件的一个结果在于应用需要有能容忍服务的故障的设计。任务服务可能因为供应商的不可靠而故障，客户端需要尽可能的优化这种场景的响应。
跟整体构架相比，这是一个缺点，因为它带来的额外的复杂性。这将让微服务团队时刻的想到服务故障的情况下用户的体验。
对于微服务而言，熔断、服务降级、限流显得格外的重要。
熔断
当多次访问一个服务失败时，应熔断，所谓的熔断就是标记该服务已停止工作，直接返回错误。直至该服务恢复正常后再重新建立连接。
服务降级
当下游的非核心业务服务停止工作后，那么上游服务应该降级，以保证核心业务不中断。比如：网上超市商城订单提交界面有一个推荐商品的功能，当推荐模块挂了后，提交订单功能不能一起挂掉，只需要暂时关闭推荐功能即可。
限流
当服务挂掉后，上游服务或者用户一般会习惯性地重试访问。当服务恢复正常，很可能因为瞬间网络流量过大又立刻挂掉。因此需要限流机制。
限流策略有很多，最简单的比如当单位时间内请求数过多时，丢弃多余的请求。另外，也可以考虑分区限流——仅拒绝来自出错服务的请求。
例如：商品服务和订单服务都需要访问促销服务，商品服务由于代码问题发起了大量请求，促销服务则只限制来自商品服务的请求，来自订单服务的请求则正常响应。
上文参照Martin Fowler的：Microservices
SpringBoot和SpringCloud与微服务之间的关系
其实SpringBoot和微服务之间并没有什么直接的联系，毕竟微服务只是一种思想。
说到微服务，在Spring的生态中，不得不提SpringCloud。我们可以通过SpringBoot+SpringCloud搭建一个微服务项目。因为SpringCloud是关注全局的服务治理框架，正好可以管理多个SpringBoot项目（服务）从而实现微服务。
值得注意的是，Spring boot可以离开Spring Cloud独立使用开发项目，但是Spring Cloud离不开Spring boot，属于依赖的关系。
spring boot使用了约定大于配置的理念，很多集成方案已经帮你选择好了，能不配置就不配置，Spring Cloud很大的一部分是基于Spring boot来实现。Spring boot专注于快速、方便集成的单个个体，Spring Cloud是关注全局的服务治理框架。
Spring boot 是 Spring 的一套快速配置脚手架，可以基于spring boot 快速开发单个微服务；Spring Cloud是一个基于Spring Boot实现的云应用开发工具。
通过下图，能够进一步了解SpringBoot和SpringCloud与微服务之间的关系
每晚睡前听你说晚安，是属于我的，最简单而持久的幸福…
