微服务架构

1，微服务架构：没有明确的定义，它采用一组服务的方式来构建一个应用，服务独立部署在不同的进程中，不同服务通过一些轻量级交互机制来通信，如RPC，HTTP等，服务可独立扩展伸缩，每个服务定义了明确的边界，不同的服务甚至可以采用不同的编程语言来实现，由独立的团队维护。

2，微服务架构特征

• 通过服务实现组件化：传统实现组件的方式是通过库，传统组件是和应用一起运行在进程中，组件的局部变化意味着整个应用的重新部署。通过服务实现组件，意味将应用拆散为一系列的服务运行在不同的进程中，那么单一服务的局部变化只需要重新部署对应的服务进程，另外将服务作为组件可以更明确的定义出组件的边界，因为服务之间的调用是跨进程的，清晰的边界和职责定义是设计时必须考虑的。
• 按业务能力来划分服务与组织团队：传统开发方式中，工程师按技能专长分层为前端层，中间层，数据层。微服务架构的开发模式不同于传统方式，它将应用按业务能力划分为不同的服务，每个服务都要求在对应业务领域的全栈软件实现，从界面到数据存储到外部沟通协作等。
• 服务即产品：传统的应用开发是基于项目模式，开发团队根据一堆功能列表开发出一个软件并交付客户，该软件应用就进入维护模式，由另一个维护团队负责，开发团队的职责结束。而微服务架构的倡导者提议避免这种项目模式，更倾向于让开发团队负责整个产品的全部生命周期。开发团队对软件在生产环境的运行负全部责任，让服务的开发者与服务的使用者形成每天的交流反馈，来自客户端的反馈有助于开发者提升服务的质量
• 智能终端与哑管道：服务作为智能终端，所有的业务智能逻辑在服务内部处理，而服务的通信尽可能的轻量化，不添加任务额外的业务规则。
• 去中心化：传统应用中倾向采用统一的技术平台来解决所有问题。微服务的架构意味着你可以针对不同的业务服务特征选择不同的技术平台，有针对性的解决具体的业务问题。
• 基础设施自动化：单一进程的传统应用被拆分成一系统的多进程服务后，意味着开发，调度，测试，集成，监控，发布的复杂都会相应增大。必须要合适的自动化基础设施来支持微服务架构模式，否则开发，运维成本将大大增加。
• Design for failure：服务独立于不同的进程，引入了额外的失败因素。任何时刻对服务的调用都可能因为服务方不可用导致失败，这要求服务的消费方需要优雅的处理此类错误。
• 进化设计：一旦采用微服务架构模式，那么在服务需要变更时我们要特别小心，服务提供者的变更可能引发服务消费者的兼容性破坏，时刻谨记服务契约的兼容性。对于解耦服务消费者与服务提供方，伯斯塔尔法则特别适用：发送时要保守，接收时要开放。最小化传送必要的信息，接收时要最大限度的容忍信息的兼容性，多余的信息不认识可以忽略，而不应该拒绝或抛出错误。

3，微服务架构实战

    API Gateway：它是一个服务器，是进入系统的唯一节点，类似设计模式的Facade，它封装内部系统的架构，并且提供API给各个客户端。它负责请求转发，合成，协议转化。提供一个服务提供点使得移动客户端可以在一个请求中检索到最终的全部数据，API　Gateway通过调用多个服务来处理一个请求并聚合多个服务的结果。

    微服务架构的进程间通信（IPC）：    一对一交互模式：请求/响应；通知；请求/异步响应。一对多的交互模式：发布/订阅；发布/异步响应。

    服务发现：服务实例运行环境是动态变化的，实例网络地址是动态变化的，客户端为了访问服务必须使用服务发现机制。

    事件驱动的数据管理：每个服务都有自己私有的数据集，分布式管理的挑战是多服务之间维护业务交易一致性及如果在多服务环境中获取一致性数据。最佳解决办法是事件驱动架构：将数据库视为消息队列，交易日志挖掘和事件源。

    微服务部署：单主机单服务实例有两种模式单虚拟机单实例和单容器单实例。

4，六种微服务架构的设计模式

    聚合器微服务模式：聚合器调用多个服务实现应用程序所需的功能，它是一个更高层次的组合微服务，对检索到的数据增加业务逻辑后进一步发布成一个新的微服务。 

    代理微服务模式：联合器模式的变种，代理不聚合数据，仅仅委派请求，也可以进行数据转换工作。

    链式微服务模式：服务A接收到请求后与服务B通信，服务B会现服务C通信，所有服务都使用同步消息传递。在整个链式调用完成之前，客户端会一直阻塞。

    分支微服务模式：聚合模式的扩展，允许调用两个微服务链。

    数据共享微服务模式：部分微服务可以共享缓存和数据库存储。

    异步消息传递微服务模式：使用消息队列代替REST请求/响应同步的阻塞的模式。