说说历史
我初出茅庐时，是JavaEE各种技术标准，与java框架百花争鸣的时代，那时JCP还主导着java的各项规范与标准落地，第三方开源框架如雨后春笋般展露出来，其中最显著的是各种MVC框架，数量之多可以和今天的RPC服务框架相比，Spring 框架此时也登场了。据说，Spring 作者参加Java组织的技术交流时，受到了当时官方的藐视，于是下定决心，靠自己的实践来解决当时分布式开发的问题。
接下来，大家都知道了，这家伙写了3本书， j2ee design and development，j2ee development without EJB , Java development with Spring Freamework。从J2ee的实践，到痛点的吐槽与最佳实践的想法，到想法的落地。看这样的书，可以了解到分布式java要解决的一些问题，和怎样做是好的最佳实践。
java的发展不仅有官方的标准制定，还有类似Spring这样的第三方的贡献，第三方实现标准，提供开源且丰富的组件，这是她和别的语言最大的区别。今天她还活跃着，但是，她会以更加优雅的形态展示在我们面前。
也因为有互联网高速发展的需求，人们思想，工具与最佳实践的积累到了一定程度，就会发生阶段性的进步和变化。
微服务就是今天用来解决分布式软件开发，集成，可用性等问题的一种思路，方式和最佳实践。
再说微服务的历史
服务 : 远程接口，使用它们的数据和逻辑
微 : 分解为更小、完全独立的组件
下面，简单整理了一下微服务的发展历程，说到服务，就要从建立远程连接开始说起：
| 概念 ,关键词 | 有关技术 | 应用模式 | 架构、思想 |
|---|---|---|---|
| 连接世界 | TCP/IP , Http ， HTML | Web服务器，静态资源 | |
| 动态内容 | CGI , PHP ，ASP, JSP | Servlet(Struts,Webwork,JSF…) Socket BIO | MVC |
| 分布式 | 模型层：EJB ,Spring Freamwork 持久化：hibernate,ibatis J2EE标准：RMI,JMS, JPA… |
MVC + EJB MVC + Spring + Hibernate Spring remote proxy: HttpIClient,Hession ,Burlap |
分布式与多层架构 |
| 面向服务 SAO, EAI |
ESB MessageBroker,ActiveMQ XML-RPC，WebService 其它：Restfull，MQ |
分布式应用 + ESB | 总线的应用集成 (退出历史舞台) |
| 服务治理 (使用服务框架) |
Netty(NIO) 服务框架 : dubbo , motan, thrift , grpc, Spring Cloud 服务注册发现，限流， 熔断降级，负载均衡 其它：HTTP2， 容器，应用编排 |
服务架构 侵入式的服务治理 各种中间件产生与使用 容器，应用编排 云原生 |
服务治理 服务去中心化 netty高性能 标准构建物容器 弹性伸缩，自愈 DEVOPS |
| 微服务（目前） | java9 模块化(java的缺陷) 反应式流 Spring Cloud Service Mesh ServerLess |
SDK模式 SideCar模式 无服务模式 |
+面向业务 |
第一阶段，连接世界(拉网线)，制定通讯协议，数据交换格式开始。
第二阶段，人们不满足仅提供静态内容，创造了动态的内容的展示方式。
第三阶段，关注分布式软件的构建方式，和各种标准与技术的落地。
第四阶段，因为各种技术的使用和软件规模的增长，导致企业应用集成成为痛点。
第五阶段，服务框架和服务治理成为主流。DEVOPS，微服务，容器和编排成为可以落地的最佳实践。
第六阶段，简化透明智能，让人专注业务逻辑。
目前，假设我们处在微服务的阶段，在这个阶段开发人员还需要关注太多的服务治理相关的技术，服务的构建，应用的部署和监控，以及各种中间件的集成和应用要做的适应，这些痛点是在目前的阶段要解决的问题。
我们也看到，这个阶段的技术标准中，不仅有官方和传统第三方的贡献，还增加了云服务提供商和CNCF（云原生技术为微服务落地的开源组织）。很热闹，一起来为微服务落地是件好事，也可以避免只能依赖某一家的技术垄断。下面来说说列出的几项技术：
java9 的模块化，这个一直时java的缺陷，早年模块化规范OSGI，没有能够成为java官方承认的模块化标准，但是，模块化落地的思想和实践是一致的，已经容纳到java9。java应用首先要做的就是依据抽象，建模确定好模块，以及模块之间的依赖关系，这是系统不断迭代升级的基础，否则需要浪费大量时间去临时解决依赖问题。
回压式流，java9增加的新东西，Spring5引入Reactor提供了实现。简单的说，就是在一次传输大量数据时，消费者可以控制流速，而生产者可以配置策略进行流控。能够解决，“避免压垮数据收件者，这样就不会阻塞任何线程”，不需要阻塞，就不需要更多的线程。回压式流，可以理解为数据传输的异步非阻塞管道，具有流控能力的数据流，从本质上解决阻塞的问题，更好的适应分布式批量数据之间的传输，增加吞吐量和改进服务之间的可靠性。
Spring Cloud，目前还是最全面的服务治理的框架，尽管还有一些不足和功能缺失。Spring，它一直倡导轻量级，最佳实践，并引领的技术的潮流。其中，也有人说Spring Cloud重，复杂。实际上服务治理要做的事情比较多，和当年MVC解决的问题大小不一样。至少，这是目前微服务落地的一种可行的方式，并且代码开源在手上也容易自主可控。如果做好依赖配置的透明，减少侵入的感觉，增加ops的能力，就会变得简单且对运维友好。
Service Mesh ， 是对Spring Cloud Client SDK实现功能的另外一种实现模式，用一个单独的Proxy 来落地服务治理的功能，或叫SideCar模式，一个应用自带一个小弟，由小弟来专门做服务治理的事，大哥就可以专注业务单元。理论不错，但是前提是你需要有这样一个服务编排的平台，门槛也不低。但是，服务或容器的编排也是当前应用devops流程的一个关键步骤或基础能力，并且，Service Mesh Proxy和语言无关，可以集成非java语言的应用， 所以Service Mesh也非常值得尝试和实践。
ServerLess 无服务，就是把服务资源透明化，你不需要管，由云服务ServerLess平台来保证资源分配，自动扩缩，高可用的事情，并提高资源的利用率，减少云服务器使用的费用。其中FAAS是它落地的一种方式，面向函数的微服务。这样可以少做很多事情，可以更加专注业务领域。让企业，开发关注的事情更少了。缺点是，需要强依赖或耦合于云服务商的实现规范。这也是一种可行的思路，并且可以指导改善微服务的落地场景，也值得尝试和使用。
开发框架的目的是可以剥离公共和特殊，让开发人员可以面向特殊的业务，业务单元之间彼此独立。这也是微服务的最终效果，目前阶段还需要更多的最佳实践来落地。
