微服务框架
目前主流的应用分为两种：
单体式应用和微服务应用，下面将具体对它们尽心能够描述。
开发单体式应用
假设你正准备开发一款与Uber和Hailo竞争的出租车调度软件，经过初步会议和需求分析，你可能会手动或者使用基于Rails、Spring Boot、Play或者Maven的生成器开始这个新项目，它的六边形架构是模块化的 ，架构图如下：
单体式应用架构
应用核心是业务逻辑，由定义服务、域对象和事件的模块完成。围绕着核心的是与外界打交道的适配器。适配器包括数据库访问组件、生产和处理消息的消息组件，以及提供API或者UI访问支持的web模块等。
尽管也是模块化逻辑，但是最终它还是会打包并部署为单体式应用。具体的格式依赖于应用语言和框架。例如，许多Java应用会被打包为WAR格式，部署在Tomcat或者Jetty上，而另外一些Java应用会被打包成自包含的JAR格式，同样，Rails和Node.js会被打包成层级目录。
这种应用开发风格很常见，因为IDE和其它工具都擅长开发一个简单应用，这类应用也很易于调试，只需要简单运行此应用，用Selenium链接UI就可以完成端到端测试。单体式应用也易于部署，只需要把打包应用拷贝到服务器端，通过在负载均衡器后端运行多个拷贝就可以轻松实现应用扩展。在早期这类应用运行的很好。
单体式应用的不足
不幸的是，这种简单方法却有很大的局限性。一个简单的应用会随着时间推移逐渐变大。在每次的sprint中，开发团队都会面对新“故事”，然后开发许多新代码。几年后，这个小而简单的应用会变成了一个巨大的怪物。这儿有一个例子，我最近和一个开发者讨论，他正在写一个工具，用来分析他们一个拥有数百万行代码的应用中JAR文件之间的依赖关系。我很确信这个代码正是很多开发者经过多年努力开发出来的一个怪物。
一旦你的应用变成一个又大又复杂的怪物，那开发团队肯定很痛苦。敏捷开发和部署举步维艰，其中最主要问题就是这个应用太复杂，以至于任何单个开发者都不可能搞懂它。因此，修正bug和正确的添加新功能变的非常困难，并且很耗时。另外，团队士气也会走下坡路。如果代码难于理解，就不可能被正确的修改。最终会走向巨大的、不可理解的泥潭。
单体式应用也会降低开发速度。应用越大，启动时间会越长。比如，最近的一个调查表明，有时候应用的启动时间居然超过了12分钟。我还听说某些应用需要40分钟启动时间。如果开发者需要经常重启应用，那么大部分时间就要在等待中渡过，生产效率受到极大影响。
另外，复杂而巨大的单体式应用也不利于持续性开发。今天，SaaS应用常态就是每天会改变很多次，而这对于单体式应用模式非常困难。另外，这种变化带来的影响并没有很好的被理解，所以不得不做很多手工测试。那么接下来，持续部署也会很艰难。
单体式应用在不同模块发生资源冲突时，扩展将会非常困难。比如，一个模块完成一个CPU敏感逻辑，应该部署在AWS EC2 Compute Optimized instances，而另外一个内存数据库模块更合适于EC2 Memory-optimized instances。然而，由于这些模块部署在一起，因此不得不在硬件选择上做一个妥协。
单体式应用另外一个问题是可靠性。因为所有模块都运行在一个进程中，任何一个模块中的一个bug，比如内存泄露，将会有可能弄垮整个进程。除此之外，因为所有应用实例都是唯一的，这个bug将会影响到整个应用的可靠性。
最后，单体式应用使得采用新架构和语言非常困难。比如，设想你有两百万行采用XYZ框架写的代码。如果想改成ABC框架，无论是时间还是成本都是非常昂贵的，即使ABC框架更好。因此，这是一个无法逾越的鸿沟。你不得不在最初选择面前低头。
总结一下：一开始你有一个很成功的关键业务应用，后来就变成了一个巨大的，无法理解的怪物。因为采用过时的，效率低的技术，使得雇佣有潜力的开发者很困难。应用无法扩展，可靠性很低，最终，敏捷性开发和部署变的无法完成。
微处理架构——处理复杂事物
许多公司，比如Amazon、eBay和NetFlix，通过采用微处理结构模式解决了上述问题。其思路不是开发一个巨大的单体式的应用，而是将应用分解为小的、互相连接的微服务。
一个微服务一般完成某个特定的功能，比如下单管理、客户管理等等。每一个微服务都是微型六角形应用，都有自己的业务逻辑和适配器。一些微服务还会发布API给其它微服务和应用客户端使用。其它微服务完成一个Web UI，运行时，每一个实例可能是一个云VM或者是Docker容器。
每一个应用功能区都使用微服务完成，另外，Web应用会被拆分成一系列简单的Web应用（比如一个对乘客，一个对出租车驾驶员）。这样的拆分对于不同用户、设备和特殊应用场景部署都更容易。
每一个后台服务开放一个REST API，许多服务本身也采用了其它服务提供的API。比如，驾驶员管理使用了告知驾驶员一个潜在需求的通知服务。UI服务激活其它服务来更新Web页面。所有服务都是采用异步的，基于消息的通讯。微服务内部机制将会在后续系列中讨论。
这种微服务架构模式深刻影响了应用和数据库之间的关系，不像传统多个服务共享一个数据库，微服务架构每个服务都有自己的数据库。另外，这种思路也影响到了企业级数据模式。同时，这种模式意味着多份数据，但是，如果你想获得微服务带来的好处，每个服务独有一个数据库是必须的，因为这种架构需要这种松耦合。下面的图演示示例应用数据库架构。
表面上看来，微服务架构模式有点像SOA，他们都由多个服务构成。但是，可以从另外一个角度看此问题，微服务架构模式是一个不包含Web服务（WS-）和ESB服务的SOA。微服务应用乐于采用简单轻量级协议，比如REST，而不是WS-，在微服务内部避免使用ESB以及ESB类似功能。微服务架构模式也拒绝使用canonical schema等SOA概念。
表面上看来，微服务架构模式有点像SOA，他们都由多个服务构成。但是，可以从另外一个角度看此问题，微服务架构模式是一个不包含Web服务（WS-）和ESB服务的SOA。微服务应用乐于采用简单轻量级协议，比如REST，而不是WS-，在微服务内部避免使用ESB以及ESB类似功能。微服务架构模式也拒绝使用canonical schema等SOA概念。
esb 总线：企业服务总线。上面标黑的这条线说的是 在微服务框架中，服务与服务之间不是通过总线，而是通过rest ful来通信。
微服务架构的好处
微服务架构模式有很多好处。首先，通过分解巨大单体式应用为多个服务方法解决了复杂性问题。在功能不变的情况下，应用被分解为多个可管理的分支或服务。每个服务都有一个用RPC-或者消息驱动API定义清楚的边界。微服务架构模式给采用单体式编码方式很难实现的功能提供了模块化的解决方案，由此，单个服务很容易开发、理解和维护。
第二，这种架构使得每个服务都可以有专门开发团队来开发。开发者可以自由选择开发技术，提供API服务。当然，许多公司试图避免混乱，只提供某些技术选择。然后，这种自由意味着开发者不需要被迫使用某项目开始时采用的过时技术，他们可以选择现在的技术。甚至于，因为服务都是相对简单，即使用现在技术重写以前代码也不是很困难的事情。
第三，微服务架构模式是每个微服务独立的部署。开发者不再需要协调其它服务部署对本服务的影响。这种改变可以加快部署速度。UI团队可以采用AB测试，快速的部署变化。微服务架构模式使得持续化部署成为可能。
最后，微服务架构模式使得每个服务独立扩展。你可以根据每个服务的规模来部署满足需求的规模。甚至于，你可以使用更适合于服务资源需求的硬件。比如，你可以在EC2 Compute Optimized instances上部署CPU敏感的服务，而在EC2 memory-optimized instances上部署内存数据库。
springboot 微服务框架
在微服务架构设计中，需要抽象出一些核心问题来统一解决，这包括九条核心问题。第一点是服务的注册中心。第二是统一的接入服务接口。第三是服务的容错和负载均衡保证服务的高可用。第四是服务的限流和降级保证核心服务的稳定性。第五是服务系统的安全及全链路日志跟踪。第六是支持多种通讯方式。第七是监控和日志管理，第八是下面详细描述各个核心问题的内容:
- 服务注册中心，主要实现服务注册与服务发现。微服务架构由一组独立的微服务组成，这些微服务之间存在一种发现机制，目前我们通过服务注册与发现来让微服务可以感知彼此，微服务框架在启动的时候，将自己的信息注册到注册中心，同时从注册中心订阅自己需要引用的服务。
- 统一的接入服务接口。由于把UI和后端服务分离。API Gateway是一个网关服务器，也可以说是进入系统的唯一节点。这跟面向对象设计模式中的Facade模式很像。API Gateway封装内部系统的架构，并且提供API给各个客户端。API Gateway还可能有其他功能，如授权、监控、负载均衡、缓存、请求分片和管理、静态响应处理等。
- 服务的容错和负载均衡保证服务的高可用。为了保证微服务的高可用，每个微服务一般会有多个实例服务提供服务，此时需要客户端在进行服务的负载均衡；目前微服务框架中，现支持常见的负载均衡策略，如随机，轮训，hash，权重，连接数，缺省是根据连接数，连接数越少，优先级越高。
- 服务的容错可以保证核心服务的连续性。在调用服务集群的时候，如果一个微服务调用异常，如超时，或者发生连接异常，网络异常，则根据容错策略进行服务容错，如果连续失败多次，则需要直接熔断，不再发起调用，这样可以防止一个服务异常拖垮所有依赖它的服务。
- 服务的限流和降级等措施可以保证核心服务的稳定性。随着访问量的增加，微服务架构设置了一个系统能够处理的极限阀值，超过这个阀值的请求则直接拒绝。同时，为了保证某些核心服务可用，需要对某些非核心业务进行降级。这些操作可以自动降级也可以人工降级。
- 安全控制和权限验证：保障系统的安全。微服务架构推荐采用token机制保证微服务的安全。用户在登录的时候会颁发给用户一个token，用户每次访问平台的时候，需要传递此token，后台校验此token的合法性，如果合法则可以访问，如果没有token或者token不合法，则禁止访问。
- 支持多种通讯方式。在微服务架构下，一般采用轻量级的方式进行通讯，每个微服务都统一对外暴露RESTFul服务，无论是前端调用后端服务，还是后端服务间的调用，都统一走RESTFul，这样统一了协议栈。
- 日志和监控管理。在微服务框架中，所有的系统调用边界、请求接入接出边界，都存在统一的日志埋点，这些日志埋点和监控系统对接，可以方便的查看系统的运行各项指标，同时也可以根据日志跟踪到一个服务从前到后的整个调用链路。
- 统一配置管理。统一的配置服务器为各应用的所有环境提供了一个中心化的外部配置。这样可以简化很多开发过程中的繁琐工作。
10.CI/CD自动化。快速完成源码构建、镜像打包、应用部署，实现微服务的高效运营。
服务注册中心 即 服务发现。可以使用的工具有etcd、Spring Cloud Consul等。
额外的补充
zookeeper 使用的是 fast paxos共识算法。
etcd 使用的是raft共识算法。
网友评论