微服务

是一种架构风格，将业务拆分成模块，部署在不同的主机上提供结构，提供服务，通过http的方式通信

单体应用架构（All in One）

将一个应用的所有应用服务都封在一个应用中，无论什么系统，都把数据库访问，web访问，各个功能放在一个war包内

• 这样的好处是方便开发测试，部署十分容易，需要扩展时只要把war包复制多份，然后放到多个服务器上在做个负载均衡
• 缺点是，哪怕要修改任何一个地方，都要停掉整个服务，重新打包、部署这个应用的war包，特别对于一个大型的应用，不可能把所有内容都放在一个应用里面，如何维护，分工合作是一个问题

架构的演变，最开始All in One模式，整个网站就只需要一个war包就能跑，但是单台计算机的能力有限 ，之后的RPC和SOA就是分布式的概念了

微服务架构

打破单体架构的结构方式，将每个功能独立出来，动态组合，需要的功能元素才拿来组合，需要多一些时可以整合多个功能元素，所以微服务架构时对功能元素进行复制，而没有对整个应用进行复制

将服务拆分，根据服务器的压力自由组装

• 好处是节省了调用资源，每个功能的服务都是一个可替换，可独立升级的软件代码

阅读知识整理：

Martin Flowar 微服务译文

小服务

轻量级通信httpapi

自动化独立部署

不同编程语言、不同存储技术

保持最低限度的集中式管理

整体风格

• 客户端、数据库、服务端
• 服务端应用是完整的，一个单独的逻辑执行，任何对系统的改动，都涉及重新构建，部署一个新版本的应用程序
• 可以通过将程序分成类、函数、命名空间，将程序划分，所有的处理请求都运行在独立的进程中
• 可以横向扩展，通过负载均衡将多个应用部署在多个服务器上
• 还不够成功，部署在云中，变更程序的一小部分，就要整体重新构建部署，很难保持模块化结构，会影响到其他模块，不能进行部分扩展

微服务架构风格：

• 把应用构建成一套服务
• 服务可以独立部署和扩展
• 每个服务有模块边界
• 服务可以用不同程序语言编写，不同团队管理
• 可以追溯到unix设计原则

微服务风格特性：

组件化（Componentization）与服务（Services）

• 组件是一个可独立替换和升级的软件单元
• 微服务架构会使用库，库定义为组件，通过函数调用
• 服务是进程外组件，通过某种机制通信，把服务当成组件，服务可以部署
• 如果应用程序时由一个单独进程中的很多库组成，对任何组件的改变都要重新部署整个应用程序
• 把程序拆分成很多服务，就只需要重新部署改变的服务
• 好的微服务架构需要更好的解耦和定义边界
• 把服务当作组件将拥有更清晰的接口，服务通过远程调用机制可以避免，紧耦合的问题，避免破坏封装性
• 远程调用比进制内调用更消耗资源，需要调整组件间的职责分配，跨越边界时会比较难
• 服务可以由多个组件开发，可以同时开发部署，例如一个应用程序继承和一个只能由这个服务使用的数据库

围绕业务功能的组织

• 将大应用程序拆分成小的部分时，需要技术、ui、服务端业务逻辑、数据库、等团队协作进行拆分
• MVC架构团队划分
  • 
• MicroService微服务团队划分
  • 围绕业务功能的组织来割分服务，跨职能团队同时负责构建和运营每个项目，产品被分割成许多单个服务，服务之间通过消息总线通信
  • 

产品不是项目

建议团队负责整个产品的声明周期，从构建到维护，

强化终端及弱化通道

• 构建不同进程间通信机制时，有许多的产品和方法能有效的加强通信机制，

• 微服务倾向于强化终端，以及弱化通道，致力于低耦合和高内聚，

• 采用单独业务逻辑，接收请求，处理业务逻辑，返回响应，

• 包含资源的API的HTTP的请求，响应和轻量级消息通信协议

• 善于利用网络，而不是限制

• 基于互联网构建系统，经常使用的资源不用声明代价就可以被开发者活运行商缓存

• 第二种做法

  • 通过轻量级消息总线发部消息
  • 通信协议单一，只负责消息到路由，RabbitMQ、ZeroMQ这样简单的异步机制都没提供
  • 依赖生产者或消费者来处理这类消息

在整体风格中，组织在进程内执行，进程间消息通信通常调用方法、或回调函数，从整体式风格到微服务最大的问题就在通信方式的变更，从内存内部的调用方式变更到远程调用，大量的不可靠通信，需要把粗粒度的方法变成更加细粒度的通信

分散治理

• 集中治理的好处是在单一平台的标准化，但是解决方案并不是万能的，
• 建议采用适当的工具解决适当的问题，比如node.js开发前端，C++提高来构建高性能组件，多数据库的切换，提高组件读取性能，
• 把整体式框架的组件拆分成不同的服务，在构建时能有更好的选择
• 微服务团队可以有不同的标准

分散数据管理

• 数据的分散管理，大型的跨系统整合，用户使用不同的售后支持可能得到不同的促销信息
• 这种问题比较有用的方式为BoundedContext（边界上下文）的领域驱动设计，DDD把复杂的领域拆分成上下文边界以及他们之间的关系，对整体框架和微服务框架都很有用，服务间有明显的关系，帮助对上下文边界进行区分，
• 整体式框架的应用使用单一逻辑数据库对数据持久化时，企业通常选择在应用的范围内选择一个数据库
• 微服务让每个服务管理自己的数据库，无论时相同数据库的不同实例，或者是不同数据库系统，这种方法叫Polyglot Persistence （混合持久化），这种方式可以用在整体架构中，但是常用于微服务架构中
• 
• 分散数据意味着管理、数据更新、处理数据、常用的事务无法保证数据的一致性，这种方法通常用在整体架构中
• 使用事务能处理一致性问题，消耗时间严重，分布式事务难以实施
• 微服务强调服务间事务的协调，认识一致性，只能通过最终一致性以及通过补偿运算处理问题
• 通常业务上允许一定的不一致满足快速响应的需求
• 采用一些恢复的进程来处理这种错误

基础设置自动化

• 云计算、AWS的发展，减少构建、发布、运维、微服务的复杂性
• 部署后需要更多的自动化测试，软件的改进能让我们自动的部署到各种新的环境中
• 

容错性设计

• 应用需要有能容忍服务故障的设计，
• NetFlix的Simian Army可以为每个应用的服务以及数据重心提供日常故障检测和恢复
• 监控系统，自动恢复，故障检测，自动化测试，提早发现故障

设计改进

• 拆分软件系统为组件时，组件可以被独立替换和更新
• 着重写一个组件而不影响协作关系，
• 服务应该能够报废，不影响长久的发展
• 使用微服务，只要发布你要修改的服务就可以了，加速发布周期