微服务：JavaEE的拯救者还是掘墓人?

引言

有人说，Java确实过于臃肿，经常“小题大做”。但PHP、Nodejs扩展方面短板太明显，做小应用可以，大型应用就玩不转了。另外，JavaEE领域有太多优秀框架可以解决开发效率的问题，事实上借用Spring等框架，开发的效率丝毫不亚于PHP。

互联网时代的Java开发者，很多都不是基于Servlet和EJB来开发Web应用，而且WebLogic、WebSphere也只会存在于大公司的存量系统中，互联网公司的Java都是Tomcat的世界。

那么，微服务能完全弥补JavaEE的短板吗对于JaveEE来说，微服务扮演的，究竟是拯救者还是掘墓人的角色

在Java问世之初，包括IBM、BEA、Oracle在内的一些巨头公司，看到了Java作为一门杰出的Web编程语言可能给他们带来的巨大商机。那么如何通过一门编程语言来赚钱呢答案就是，使用这门语言构建复杂无比的服务器，让那些大公司支付一大笔费用来购买这些服务器。于是紧接着就出现了JavaEE规范、JSR规范，以及WebLogic、WebSphere等服务器中间件。

在这些服务器上面部署了大型的程序包，它们运行缓慢，消耗大量的内存。基于这些容器的开发和调试对开发人员来说简直就是噩梦，作为对他们的补偿，他们从雇主那里获得了丰厚的报酬。

因为耗资巨大，几乎找不到一家公司可以使用合理的费用长时间地支持Java。如果你要用Java构建一个网站，你必须支付一大笔费用来运行这些服务器，哪怕你只用到了Servlet容器。在很长一段时间里，Java被用在企业和公司里，因为只有这些大公司能够负担得起数百万美元的服务器费用，并为那些企业级开发人员支付高额的薪水。

RodJohnson在2003年发布了Spring框架，Spring提供了IoC和对POJO的支持，帮助开发人员逃脱EJB魔掌。开发效率因此得到大幅的提升，大量开发人员转向Spring，把EJB丢在一边。应用服务器开发商看到了这一点，他们在JavaEE5里提供了一些可以减轻开发人员负担的特性。可惜的是，Spring被一路追捧，人们几乎把它跟JavaEE容器混为一谈，它仍然运行在JavaEE的Servlet容器里，这些容器沿用的是十年前的设计，并没有考虑到多核CPU和NIO。

在这期间，PHP奋起直追。PHP使用更少的内存和资源，得到很多公司的支持。一些CMS平台，比如WordPress、Drupal等都是基于PHP构建的，这些平台吸引了大批PHP开发人员。不过，虽然PHP仍然是现今最流行的编程语言，但它也有自己的短板。它运行速度不是很快，而且难以横向扩展。

2009年，RyanDahl启动了Nodejs项目，它支持异步非阻塞的、基于事件驱动的I/O。如果服务器的线程使用得当，Nodejs可以极大地提升响应速度，单个服务器的吞吐量可以媲美一个JavaEE服务器集群。Nodejs是一个很好的作品，但它也有自己的局限性。Nodejs难以扩展，也难以与遗留的系统集成。

2014年，Undertow出现了，它是一个基于Java的非阻塞Web服务器。从#的测试结果来看，在一个价值8000美金的戴尔服务器上，它可以每秒钟处理几百万个请求，而谷歌需要使用一个集群才能处理一百万个同样的请求。它是轻量级的，它的核心部分只需要1M内存，它还包含了一个内嵌的服务器，这个服务器使用不到4M的堆内存。

基于UndertowCore构建的LightJavaFramework是一个微服务容器，它支持设计驱动及生成代码，并支持运行时安全和运行时验证。

JavaEE厂商多年前，JavaEE厂商，比如Oracle和IBM，他们花费数亿美元开发应用服务器(WebLogic和WebSphere)，这些服务器以数百万的价格卖给了大型组织。但现在这些服务器卖不动了，因为JBoss迅速抢占了市场份额，Oracle对JavaEE的支持正在走下坡路：

#/story/16/07/02/1639241/oracle-may-have-stopped-funding-and-developing-java-ee

随着微服务越来越多地受到关注，这些应用服务器很难有好的销量，因为这些服务器更适合用来部署单体应用。有一个包含了数百个EJB的应用，为了在WebLogic上测试一行代码改动，居然用了45分钟时间。

JavaEE客户

从客户角度来看，耗费巨资购买这些服务器是不值得的，因为JavaEE所承诺的未必都是真的。一个为WebSphere开发的应用无法部署在WebLogic上，所以你需要花更多的钱去升级服务器，因为厂商可能不再支持旧版的服务器，而这样的更新会花费你数百万美元。

于是一些聪明人不禁要问，为什么我们要把应用部署在这些庞然大物上为什么我们要把应用打包成一个ear包或war包，而不是jar包为什么我们不能把大型的应用拆分成更小的块，让它们可以独立部署和扩展

微服务

微服务是这些问题的解药。Wikipedia把微服务定义为“一种软件架构风格，复杂的应用由一些独立的进程组成，这些进程使用与语言无关的API进行交互。这些进程服务规模很小，高度离散，聚焦在一个很小的任务上，使用模块化方式来构建系统”。

微服务架构让构建应用变得更加容易，而且应用被拆分成单独的服务，这些服务可以被任意组合。每个服务可以被独立部署，也可以被组合成一个应用。这些服务还可能会被其他应用依赖。它加快了服务的开发速度，因为只要定义好接口，服务可以并行开发。

微服务具备d性和伸缩性。微服务不只依赖单个服务器和部署，它们可以被发布到多个机器上，或者多个数据中心及其它任何可用的区域。如果一个服务失效，可以启动另外一个。因为整个应用被分解成了微服务(小型服务)，可以很容易地对其中某些热门的服务进行横向扩展。

如果你曾经使用过COM、DCOM、CORBA、EJB、OSGi、J2EE、SOAP和SOA等，那么你就会知道服务和组件并不是什么新生事物。企业在使用组件方面存在的一个最大问题是他们依赖大型的硬件服务器，并在同一个服务器上运行很多应用。我们有EJB、WAR包和EAR包，以及各种组件包，因为服务器资源太过昂贵，要尽可能地物尽其用。

不过从最近几年的发展情况来看，之前的方式有些落伍。 *** 作系统服务器一直在变化，虚拟资源可以被当成组件发布，比如EC2、OpenStack、Vagrant和Docker。世界变了。微服务架构看到了这种趋势，硬件、云技术、多核CPU和虚拟技术也在发展，所以我们要改变以前的开发方式。

在开始新项目的时候不要再使用EAR包或WAR包了。现在我们可以在Docker里运行JVM，Docker只不过是一个进程，但它可以表现得像一个 *** 作系统一样。Docker运行在云端的 *** 作系统上，而云端的 *** 作系统运行在虚拟机里，虚拟机运行在Linux服务器上。这些服务器不是归谁所有，而是被很多互不相识的人共享。如果出现流量高峰怎么办很简单，使用更多的服务器实例。这就是为什么要把Java微服务运行在一个单独的进程里，而不是JavaEE容器或servlet容器。

微服务一般会提供基于>

使用微服务架构的应用程序应该是模块化、可编程和可组合的。微服务之间可以相互替换。应用程序的局部可以被重写或改进，而不会影响到整个应用。如果所有的组件都提供了可编程的API，那么微服务之间的交互就会变得更简单(永远不要相信那些不能通过curl访问的微服务)。

随着微服务逐渐流行起来，很多厂商开始尝试把他们的JavaEEWeb服务转成微服务，这样他们就可以继续卖他们的过时产品，APIGateway就是这些厂商中的一个。

JasonBloomberg是Intellyx的主席，他在一篇文章里指出了传统Web服务和微服务的区别，并对把传统Web服务转成微服务的趋势提出了质疑：

#/dangers-microservices-washing-get-value-strip-away-hype

微服务不是企业服务总线里的Web服务，也不是传统的面向服务架构，尽管它沿袭了SOA的一些基本概念。从根本上来说，微服务跟SOA是不一样的，因为整个环境已经发生了彻底的转变。

微服务架构的环境是没有边界的：端到端，基于云的应用程序运行在完全虚拟和容器化的基础设施上。容器把应用程序和服务组件化，DevOps为IT基础设施提供框架，帮助自动化开发、部署和管理环境。

虽然容器对微服务来说不是必需的，不过微服务可以很容易地运行在容器里。况且，把非微服务的代码部署在容器里不是一个明智的选择。

Docker和其他容器技术在某种程度上已经被视为微服务的最好伴侣。容器是运行微服务的最小资源子集。Docker简化了微服务的开发，让集成测试变得更简单。

容器有助于微服务开发，但不是必需的。Docker也可以被用来部署单体应用。微服务与容器可以很好地相融并进，不过微服务包含的东西远比容器多!

结论

应用开发的风格这几年一直在变化，而微服务变得越来越流行。大公司把大型应用拆分成可以单独部署的小型应用，这些小型应用被部署在云端的容器里。开源微服务框架LightJava为这些运行在容器里的微服务提供了很多特性，它支持设计驱动，开发者只需要把注意力专注在业务逻辑上，剩下的事情可以由框架和DevOps流程来处理。

那么问题来了，你怎么看

简单地说，微服务架构就是以业务域或业务功能为边界，将一个大而全的应用拆分为可以独立开发，独立部署，独立测试，独立运行的一组小的应用，并且使用轻量级，通用的机制在这组应用间进行通信。
主流的微服务包括：
1、SpringCloud
Spring Cloud , 来自Spring，具有Spring 社区的强大支撑，还有Netflix强大的后盾与技术输出。Netflix作为一家成功实践微服务架构的互联网公司在几年前就把几乎整个微服务框架栈开源贡献给了社区，这些框架开源的整套服务架构套件是Spring Cloud的核心。
- Eureka:服务注册发现框架；
- Zuul:服务网关；
- Karyon：服务端框架；
- Ribbon：客户端框架；
- Hystrix：服务容错组件；
- Archaius：服务配置组件；
- Servo：Metrics组件；
- Blitz4j：日志组件；
2、Dubbo
Dobbo是一个分布式服务框架，是阿里开放的微服务化治理框架，致力于提高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。其核心部分(官网)
- 远程通讯: 提供对多种基于长连接的NIO框架抽象封装，包括多种线程模型，序列化，以及“请求-响应”模式的信息交换方式；
- 集群容错: 提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡，失败容错，地址路由，动态配置等集群支持；
- 自动发现: 基于注册中心目录服务，使服务消费方能动态的查找服务提供方，使地址透明，使服务提供方可以平滑增加或减少机器。
Dubbo 也是采用全 Spring 配置方式，透明化接入应用，对应用没有任何 API 侵入，只需用 Spring 加载 Dubbo的配置即可，Dubbo 基于 Spring 的 Schema 扩展进行加载。当然也支持官方不推荐的 API 调用方式。
3、lstio
lstio 作为用于微服务聚合层管理的新锐项目，是Google、IBM、Lyft（海外共享出行公司、Uber劲敌），首个共同联合开源的项目，提供了统一的连接，安全，管理和监控微服务的方案。
目前首个测试版是针对Kubernetes环境的，社区宣称在未来几个月内会为虚拟机和Cloud Foundry 等其他环境增加支持。lstio将 流量管理添加到微服务中，并为增值功能（如安全性、监控、路由、连接管理和策略）创造了基础。
- >两年前，第一次真正接触微服务的概念，但也只是简单地进行了使用，当时技术栈主要是 Spring Boot,那时 Spring Cloud 也比较流行，但是由于各种原因，并没有转向这套（甚至用 zookeeper 实现了简单的服务发现），理论上来说，用了 Spring Boot 再转向 Spring Cloud 应该是很正常的事情。当时也认为 Spring Cloud 各种理念很高级，实现上也不错，也有 Netflix 等之类的大公司背书，而且和 Spring 天然集成的，使用起来还是比较方便。当时可能觉得其他的 RPC 框架：如 Dubbo 和 Spring Cloud 相比简直差了一个档次，可能大家都认为 Spring Cloud 是未来。

从第一家公司离职后，去了另外一家公司，发现一个很奇怪的特点，这家公司的技术比较保守，基本还是十年前或者五六年前的技术架构。记得之前看过一本书上说过，技术不与时俱进，那就相当于自取灭亡，特别是技术驱动型公司，如果一直停滞不前，那就相当于你拿几十年前的武器和别人战斗，那结果自然是必然的。为什么技术要与时俱进，不是因为有了新技术就要去使用它，而是因为新技术往往可以提高业务的运转效率，同时也可以降低成本。不过在这个公司待了两个月，还是觉得有可取的地方，第一点是对代码质量的追求，由于业务的体量和特殊性（大概是亿级），所以对代码有较高的要求；第二点是对微服务整体架构的深入，虽然这个系统没有上 Spring Cloud ,甚至 Spring Boot 都没有，还是很老的一个架构，但其中微服务的思想已经有了，比如服务的拆分，服务的水平扩展，基于 Dubbo 的一些服务发现和治理，整体来说已经算是不错了，但是也总在思考，感觉还是少了什么东西。
容器化和 CI/CD

后来又到了一家比较年轻活跃的公司，接触到 Docker 的大规模使用以及 CI/CD，也是在这里，形成了整个对微服务完整生命周期的理解。 Docker 其实流行也很久了， 但是真正线上使用的并没有那么多，最近随着 Kubernetes（ k8s ） 的流行，更多公司也开始关注起来。

首先为什么服务要容器化，第一点是不再依赖于运行环境，只要有 Docker 就可以跑起来，无论你是什么发行版的 Linux 系统，还是 Windows，Mac。这有点像 JVM，屏蔽底层的细节，一次编写，到处运行，用在容器上就是一次构建，到处运行。第二点是容器化可以更好的进行持续集成，由于第一点的缘故，部署一个服务容器将非常快捷，这更加适合目前 devops 的理念。

持续集成(Continuous Integration)简称 CI ,持续部署（Continuous Deployment)简称 CD,如果微服务不把 CI/CD 放在首位，那必然整个流程就是不流畅的。有些公司还是手动本地构建包，然后 上传 到服务器上跑起来，进行这样的人肉运维，人肉上线，要么考虑一下，是不是整个 CI/CD 有问题，或者根本就没有 CI/CD 。其次 CI/CD 流程要做到每次构建自动跑单元测试，集成测试，以及 API 测试，UI 测试等等，这些流程也没有自动化的话，也谈不上完整的 CI/CD。如果没有经过这些流程把包直接上传到服务器，不出问题，那应该要烧柱香，拜拜佛。

云原生应用和服务网格

云原生应用遵循 Twelve-Factor ，云原生应用是为了解决传统应用发布升级流程缓慢、架构复杂，可维护性差而提出的的一个思想集合，集中了 微服务，devops，云等多种思想。

云原生应用应用可以跑在任意一家云服务商上，也可以实现多家服务商同时使用，同时也支持公有云和私有云的混合部署，这只是它的一个特点，更多的特点还是集中在解决传统应用面临的问题，如灰度发布，不停机发布，A/B Test, 快速回滚，服务治理等。
服务网格（Service Mesh）是一个比较新的概念，但是核心思想并不新。Spring Cloud 以框架的形式侵入到程序中来解决微服务的各种问题，理论上来说，应该是效率最高，最灵活的一种做法。但是侵入性太强，而且只能 Spring 这套，异构语言的系统玩不转。Service Mesh 从另外一个角度来解决这个问题，也就是 sidecar 和 proxy，这样虽然性能上有些损失，但是扩展性却是比较灵活的，将这些基础能力（服务发现，服务治理，熔断限流，监控等）下放到基础设施中，做到对应用程序透明，是一个不错的进步。写业务逻辑不需要再去和这些东西纠结，代码逻辑也变得十分明朗。同时这样也解决了异构语言系统的问题，无论什么语言，都是可以完美的工作在一起，简直是一个完美世界。但是但是但是 Service Mesh 由于还比较新，目前还不能进行生产环境使用，就拿目前最流行的 Istio 来说，目前只发布了 08 版本，还不能实际使用，估计 10 也不行，可能得 12 才推荐生产，所以现在就面临一个困境，Service Mesh 是一个好东西，但是我们却用不了，呜呼哀哉。

Spring Cloud 和 Service Mesh

首先两者解决问题的方式不一样，Spring Cloud 是直接的方式，Service Mesh 是委婉的方式，这可能会造就两者之后的命运。如果目前已经上了 Spring Cloud 或者其他的，系统已经具有基础的服务治理能力，先不要考虑 Service Mesh ，要先去考虑容器化和 CI/CD ；如果没有太多的 历史 负担，则是可以考虑。

总结

技术发展太快，不能停滞不前，也不能盲目追风。当年的 SSH 也只剩下了 Spring，可是有人说 Spring 只能一个季节用，但是 Service Mesh 整年都可以用，好像很有道理。最后，路漫漫而修远兮，吾将上下而求索。

微服务架构是一项在云中部署应用和服务的新技术。

大部分围绕微服务的争论都集中在容器或其他技术是否能很好的实施微服务，而红帽说API应该是重点。

微服务架构相关介绍：

微服务可以在“自己的程序”中运行，并通过“轻量级设备与>

在服务公开中，许多服务都可以被内部独立进程所限制。如果其中任何一个服务需要增加某种功能，那么就必须缩小进程范围。在微服务架构中，只需要在特定的某种服务中增加所需功能，而不影响整体进程的架构。

微服务不需要像普通服务那样成为一种独立的功能或者独立的资源。定义中称，微服务是需要与业务能力相匹配，这种说法完全正确。不幸的是，仍然意味着，如果能力模型粒度的设计是错误的，那么，我们就必须付出很多代价。

如果你阅读了Fowler的整篇文章，你会发现，其中的指导建议是非常实用的。在决定将所有组件组合到一起时，开发人员需要非常确信这些组件都会有所改变，并且规模也会发生变化。服务粒度越粗，就越难以符合规定原则。

服务粒度越细，就越能够灵活地降低变化和负载所带来的影响。然而，利弊之间的权衡过程是非常复杂的，我们要在配置和资金模型的基础上考虑到基础设施的成本问题。

Tars。
根据查询CSDN网可知，Tars是一个支持多语言内嵌服务治理功能的框槛，能与 DevOps 比较好的协同开发。提供了包含开发、运维、以及测试的一整套解决方案。通过Tars可快速用微服务的方式构建自己高可用的分布式应用，并实现完整有效的服务治理。
Tars是一个跨平台、跨语言的软件运行环境，是基于service mesh设计理念实现的开发框架。Tars集可扩展协议编解码、高性能 RPC 通信框架、名字路由与发现、发布监控、日志统计、配置管理等于一体。

---