微服务架构

微服务架构（microservice）：
微服务架构是一项在云中部署应用和服务的新技术。大部分围绕微服务的争论都集中在容器或其他技术是否能很好的实施微服务，
而红帽说API应该是重点。微服务可以在“自己的程序”中运行，并通过“轻量级设备与HTTP型API进行沟通”。关键在于该服务
可以在自己的程序中运行。通过这一点我们就可以将服务公开与微服务架构（在现有系统中分布一个API）区分开来。在服务公
开中，许多服务都可以被内部独立进程所限制。如果其中任何一个服务需要增加某种功能，那么就必须缩小进程范围。在微服务
架构中，只需要在特定的某种服务中增加所需功能，而不影响整体进程。

一个微服务一般完成某个特定的功能，比如订单管理、客户管理等。每个微服务都是一个微型应用，有着自己的六边形架构，
包括商业逻辑和各种接口。有的微服务通过暴露API被别的微服务或者应用客户端所有；有的服务则通过网页UI实现。在运
行时，每个实例通常是一个云虚拟机或者Docker容器。

概念：
微服务不需要像普通服务那样成为一种独立的功能或者独立的资源。定义中称，微服务是需要与业务能力相匹配。
在决定将所有组件组合到一起时，开发人员需要非常确信这些组件都会有所改变，并且规模也会发生变化。服务粒度越粗，就越
难以符合规定原则。服务粒度越细，就越能够灵活地降低变化和负载所带来的影响。然而，利弊之间的权衡过程是非常复杂的，
我们要在配置和资金模型的基础上考虑到基础设施的成本问题。

特点：
服务的基本思想在于考虑围绕着业务领域组件来创建应用，这些应用可独立地进行开发、管理和加速。在分散的组件中使用微服
务云架构和平台，使部署、管理和服务功能交付变得更加简单。微服务是利用组织的服务投资组合，然后基于业务领域功能分解
它们，在看到服务投资组合之前，它还是一个业务领域。
微服务这一概念出现于2012年，是因软件作者Martin Fowler而流行，他承认这并没有精确地定义出这一架构形式，虽然围绕
业务能力、自动化部署、终端智能以及语言和数据的分散控制有一些常见的特性。

微服务架构开发工具：
微服Seneca是构建务框架的工具，然后把它们构建到测试和部署的devops工作流中。构建和部署基于服务的应用程序都很好，
但却无法维护，这一点很折磨人。还要在服务周围实现一些 持续交付模型的形式，然后使用它来管理并发布更新——这是一个比
编写代码更棘手的问题。使用微服务构建现代化应用程序是很有意义的，因为它让你既利用了扩展横向扩展架构，也利用纵向扩
展架构；还额外得到API的组合，且在整个业务中可重复利用。可能，每一分钟构都在交付新服务，这样你就必须拥有一个敏捷
的且响应的应用程序平台，这一平台一直在不断改进中。

微服务架构强调的第一个重点就是业务系统需要彻底的组件化和服务化，原有的单个业务系统会被拆分为多个可以独立开发，
设计，运行和运维的小应用。这些小应用之间通过服务完成交互和集成。每个小应用从前端web ui，到控制层，逻辑层，数
据库访问，数据库都是完全独立的一套。在这里我们不用组件而用小应用这个词更合适，每个小应用除了完成自身本身的业务
功能外，重点就是还需要消费外部其它应用暴露的服务，同时也将自身的能力朝外的部发布为服务。