编程架构未来趋势---微服务详解

微服务是最近的一个大热门，越来越多的公司开始把之前的单体架构向微服务架构过渡，市场上,对于懂得微服务的人才需求越来越大,学好微服务,是程序们升职加薪,打倒高帅富,迎娶白富美,走向人生巅峰的必备技能...但是什么是微服务?微服务具体要掌握哪些技能?

 

概念

微服务是一种用于构建应用的架构方案。微服务架构有别于更为传统的单体式方案，可将应用拆分成多个核心功能。每个功能都被称为一项服务，可以单独构建和部署，这意味着各项服务在工作（和出现故障）时不会相互影响。

新问题又来了,什么是单体式方案?以一个简单的线上商城为例,单体式方案结构如图:

一个软件应用，往往会将应用所有功能都开发和打包在一起,当然有些大一些应用在部署上可能会用到负载均衡,但是架构上还是归属于单体式方案,这样部署就会导致:

1.代码臃肿，应用启动时间长

2.应用容错性差，某个小小功能的程序错误可能导致整个系统完蛋；

3.可扩展性差,牵一发而动全身.

4.开发协作困难,这个其实也是跟耦合相关.(所以高内聚低耦合思想要贯彻落实)

什么是微服务架构模式,来个简单例子:

微服务就是应用的各项核心功能服务均可独立运行。这样的法,即使某一个功能运行处故障了,也不会导致全体功能全部完蛋,微服务的出现就是因为原来单体应用架构已经无法满足当前互联网产品的技术需求.

 

微服务架构的优势

1.微服务可通过分布式部署，大幅提升日常工作效率。还可以并行开发多个微服务。这意味着更多开发人员可以同时开发同一个应用，进而缩短开发所需的时间

2.只要确保正确构建，这些独立的服务就不会彼此影响。这意味着，一个服务出现故障不会导致整个应用下线，让项目更加稳定,这一点与单体式应用模型不同。

3.由于使用了多语言 API，所以开发人员可以根据需要实现的功能，自由选用最适合的语言和技术。这样可以真正做到物尽其用.

4.可扩展度高,可以跟着项目需求,技术更新,轻松扩展

 

微服务9大特性

每一个人的思想都是不一样的,由于存在环境、资源、需求等各种因素的影响，因此在对一个大型系统架构的设计与实施过程中几乎不会出现完全相同的架构设计。对于微服务架构而言更是如此，由于微服务架构只是一种建议，不是硬性规定，架构师通常会根据自身理解和实际情况来进行设计，并在发展的过程中不断演进和完善,就跟面向对象的设计模式一样,微服务也存在九大特征,通过这9大特性的学习，对于架构设计有着指导性意义。

一.服务组件化：

在微服务架构中，需要我们对服务进行组件化分解，服务是一种进程外的组件，它通过HTTP等通信协议进行协作，而不是像传统组件那样镶入式的方式协同工作，每一个服务都独立开发、部署、可以有效避免一个服务的修改引起整个系统的重新部署。

二.按业务组织团队：

在实施微服务架构时，需要采用不同的团队分割方法。由于每一个服务都是针对特定的业务的宽栈或者全栈实现的，纪要负责数据的持久化存储，又要负责用户接口定义等各种跨专业领域的职能。因此面对大型项目的时候，对于微服务团队的拆分更加建议按业务线的方法进行拆分，一方面可以有效的减少服务内部修改所产生的内耗，另一方面，团队边界可以变得更为清晰。

三.做产品的态度：

在微服务架构团队中，每个小团队都应该以做产品的方式，，对其整个生命周期负责，而不是像传统项目开发那样，交付给测试，运维为目标

四.智能端点和哑管道：

由于各个服务不在一个进程中，组件间的通信模式发生了改变，原本进程内的方法调用变成了RPC方式的调用，会导致微服务之间产生烦琐的通信，使得系统表现更为糟糕，所以我们需要更粗粒度的通信协议：

在微服务架构中，通常会使用一下两种服务调用方法：

（1）使用HTTP的RESTful API或者轻量级的消息发送协议，实现消息传递与服务调用的处触发。

(2) 通过在轻量级消息总线上传递消息，类似RabbitMQ等一些提供可靠异步交换的中间体。

在极度强调性能的情况下，还有可能会使用二进制的消息发送协议，例如protobuf

五.去中心化治理：

在整个微服务架构，通过采用轻量级的契约定义接口，使得我们队服务本身的具体技术平台不再那么敏感，这样整个微服务架构系统中的各个组件就能针对不同的业务特点选择不同的技术平台。

六.去中心化管理数据：

在实施微服务架构时，希望每一个服务自己来管理其数据库，这就是数据管理的去中心化，虽然数据管理的去中心化让数据管理更加细致化，让数据存储和性能达到最优，但是不同的数据库实例，数据一致性也成了微服务架构中亟待解决的问题之一，分布式事务本身实现的难度就非常大，所以在微服务架构中，我们更强调各服务之间进行”无事务“的调用，而对数据一致性，只要求数据在最后的处理状态是一致的即可。

七.基础设施自动化：

在微服务架构中，务必从一开始就构建起”持续交付“平台来支撑整个实施过程；

八.通错设计：

在微服务架构中，快速检测出故障源并尽可能地自动恢复服务是必须被设计考虑的，通常我们都希望在每个服务中实现监控和日志记录的组件。比如：服务状态、断路器状态、吞吐量、网络延迟等关键数据的仪表盘等。

九.演进式设计:

 其实通过上面的学习，我们可以发现要实施一个完美的微服务架构，需要考虑很多东西且成本也挺大的，对于一些没有过足够经验的团队来说，极易可能付出比单体架构应用更多的代价。

因此在很多情况下，架构师都会以演进的方式进行系统的构建，也就是说一个好的架构不是设计出来的，而是演进出来的。在初期，一般会以单体架构来设计和实施，一方面是因为系统初期体量不会太大，构建和维护成本都不高；另一方面初期的核心业务在后期通常也不会发生巨大的变化。随着系统的发展或者业务的需要，架构师会将一些经常变动或者是有一段时间效应的内容进行微服务处理，并逐渐将原来在单体系统中多变的模块拆分出来，而稳定不太变化的模块就形成了一个核心微服务存在于整个架构中。

 

微服务带来的挑战

在实施微服务之前，有必要知道因为微服务的拆分而引发了诸多原本在单体应用中没有的问题和挑战：

（1）运维的新高度。 在微服务架构中，由于系统的拆分，使得运维人员需要维护的进程数量大大增加，这就要求运维人员具备一定的开发能力来编排运维过程并让它们能自动运行起来。

（2）接口的一致性。 虽然我们拆分了服务，但是业务逻辑上的依赖并不会消除，只是从单体应用中的代码依赖变为了微服务间的通信依赖。这就使得开发者对原有接口进行了一丝修改，那么与之对应的交互方也需要协调这样的改变来进行发布，以保证接口的正确调用。也就是说此时需要更完善的接口和版本管理，或者是严格遵循开闭原则。

（3）分布式的复杂性。 由于拆分后的各个微服务都是独立部署并运行在各自的进程内，它们只能通过通信来进行协作，所以分布式环境的问题都是微服务架构设计时需要考虑的重要因素，如网络延迟、分布式事务、异步消息等。

尽管微服务架构中存在很多缺点，但是你知道的凡是都有两面性，关键在于如何取舍，当你觉得微服务架构中实现的敏捷开发、自动化部署等是你着重需要考虑的问题，那么此时选择微服务架构是不错的选择。

 

微服务需要掌握的技术

光会理论啥也不是,最重要还是需要能写出来,掌握微服务我们需要掌握哪些技术和框架?

现在编程界,各种框架数不胜数,我们在解决一个问题,选择框架时候,经常会陷入选择困难症,到底用哪个好,Spring Cloud的出现就解决这样的问题,Spring Cloud是一系列框架的有序集合。它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等，都可以用Spring Boot的开发风格做到一键启动和部署。Spring Cloud并没有重复制造轮子，它只是将各家公司开发的比较成熟、经得起实际考验的服务框架组合起来，通过Spring Boot风格进行再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。

Spring Cloud简介

Spring Cloud是一个基于Spring Boot实现的微服务架构开发工具，它为微服务架构中涉及的配置管理、服务治理、断路器、智能路由、微代理、控制总线、全局锁、决策竞选、分布式会话和集群状态管理等操作提供了一种简单的开发方式。

Spring Cloud包含了很多子项目，如下所示：

（1）Spring Cloud Config：配置管理，支持使用Git存储配置内容，可以使用它来实现应用配置的外部化存储，并支持客户端配置信息刷新、加密/解密配置内容等；

（2）Spring Cloud Netflix：这是Spring Cloud的核心组件，对多个Netflix OSS开源套件进行整合：

• Eureka：服务治理组件，包含服务注册中心、服务注册与服务发现机制的实现；

• Hystrix：容错管理组件，实现断路器模式，帮助服务依赖中出现的延迟和为故障提供强大的容错能力；

• Ribbon：客户端负载均衡的服务调用组件；

• Feign：基于Ribbon和Hystrix的声明式服务调用组件；

• Zuul：网关组件，提供智能路由、访问过滤等功能；

• Archaius：外部化配置组件。

（3）Spring Cloud Bus：事件、消息总线，用于传播集群中的状态变化或事件，以触发后续的处理，如用来动态刷新配置信息等；

（4）Spring Cloud Cluster：针对Zookeeper、Redis、Hazelcast、Consul的选举算法和通用模式的实现；

（5）Spring Cloud Cloudfoundry：与Pivotal Cloudfoundry的整合支持；（6）Spring Cloud Consul：服务发现与配置管理工具；

（7）Spring Cloud Stream：通过Redis、RabbitMQ或者Kafka实现的消费微服务，可以通过简单的声明式模型来发送和接收消息；

（8）Spring Cloud AWS：用于简化整合Amazon Web Service的组件；

（9）Spring Cloud Security：安全工具包，提供在Zuul代理中对于OAuth2客户端请求的中继器；

（10）Spring Cloud Sleuth：Spring Cloud应用的分布式服务跟踪实现，可以完美的整合Zipkin；

（11）Spring Cloud Zookeeper：基于Zookeeper的服务发现与配置管理组件；

（12）Spring Cloud Starters：Spring Cloud的基础组件，它是基于Spring Boot风格项目的基础依赖模块；

（13）Spring Cloud CLI：用于在Groovy中快速创建Spring Cloud应用的Spring Boot CLI插件。

当然除了Spring Cloud,还有很多优秀的开源框架特值得我们去学习,

1. Tars

Tars是将腾讯内部使用的微服务架构TAF（Total Application FramTars是将腾讯内部使用的微服务架构TAF（Total Application Framework）多年的实践成果总结而成的开源项目。基于Tars服务使用Tars协议的高性能RPC开发框架，同时配套一体化的服务治理平台，帮助个人或者企业快速的以微服务的方式构建自己稳定可靠的分布式应用。最核心是它支持PHP,JAVA,GO,C++等多种语言,不管你做啥后端语言的,都可以学习.

TarsCloud/Tarsgit地址:

https://github.com/TarsCloud/Tars​github.com

 

2.Dubbo

国内最早开源的 RPC 框架，由阿里巴巴公司开发并于 2011 年末对外开源，但是仅支持 Java 语言。

官方地址:

home​dubbo.apache.org

3.gRPC

一开始由 google 开发，是一款语言中立、平台中立、开源的远程过程调用(RPC)系统。

官网：

gRPC​grpc.io

当然技术无止境,像百度的Disconf、360的QConf、淘宝的Diamond、当当网的Elastic-Job、京东的Hydra等等技术,都值得我们学习.

没有最完美的技术,只有最适合的,找好自己的路,选择好自己方向才是最重要的.