微服务体系的发展并不是一蹴而就的，经过了2014年前后的低潮期，微服务概念顶层的泡沫逐渐褪去，那些真正能够在企业落地的实践在一轮又一轮的大浪淘沙后被甄别、沉淀。在软件开发行业，微软服务正从一个流行术语转向实战战略。随着越来越多的企业开始采用微服务，行业内也累积了不少的经验教训。
2017年秋天，红帽对客户进行一项微服务调查，发现了几个有趣的趋势，今天小编就跟大家分享一下。
1、微服务被用来重新架构现有的应用程序
技术提供商似乎很重视将微服务定位为只用于新项目的市场，然而，调查显示，企业也在使用微服务来重新架构现有和遗留的应用程序。
67%的红帽中间件客户和79%的红帽OpenShift客户反应了这一点，这些数据告诉我们，微服务在他们的IT转型过程中为用户提供了相应的价值——不管他们只是想更新当前的应用程序组合，还是正在准备新的计划。因此，如果只关注微服务的Greenfield项目，那么需要开始评估现有的应用程序进行微服务重新架构可能是一个好注意。微服务引入了一系列已经被证明的利益，不仅适用于新项目，也适用于现有的项目。
2、客户更喜欢多运行时/多技术/多框架的微服务
另外，87%的受访者表示，他们正在使用或考虑多种技术去开发微服务。
因此，若正在使用单一的运行时、技术或框架进行微服务开发，那么不妨开始查看其它运行时、技术和框架，并选择最适合正在尝试解决问题的框架是最明智的选择，换句话说，现在是将单一技术方法扩展多技术方法的最好时机。
3、微服务的六大好处
被调查者发现，他们已经通过微服务获得了很多的好处，位居前六的是：
持续集成（CI）/持续部署（CD）
敏捷性
提高可伸缩性
更快的交付时间
提高开发人员的生产效率
更容易调试和维护
如果对为新项目使用微服务或重新构建现有应用程序而犹豫不决，那就不要再徘徊了，上面的这些好处是用户最关注的问题，而且他们也确确实实得到了相应的好处。
4、微服务效益可以在二至十二个月内实现
正如调查结果所展现的那样，客户可以很快就能开始从微服务中获得收益，为了保持并提高自身的竞争力，当涉及到微服务时，没有道理在一旁犹豫不决，迟迟不能下定决心。
5、实施落地微服务的挑战
正如数人云之前给大家分享线下Meetup中技术大牛演讲中所说的一样，实现微服务其实并不能解决所有问题，它并非灵丹妙药，甚至自身也有极大的挑战，根据报告显示，目前微服务所面临的前四大挑战分别是：
企业文化和组织结构上的挑战
微服务管理
诊断和监控
时间及资源管理
微服务开发需要对软件的开发模式进行转变，对于哪些喜欢现状的企业来说，这首先就是一个挑战，因为他们熟悉当前的流程和过程，此外，还必须学习新的运行时、技术和框架，这也可能对那些不想投资于重新培训他们的劳动力的企业具有一定的挑战性，因为技术与他们的专长不同，如果再培训不是一种好的选择，那么在市场上寻找具有适当经验和背景的资源，可能是另外一个挑战。
随后微服务有两个技术挑战：微服务管理、诊断以及监控，应该在市场上评估可用的解决方案，以提供这些技术挑战的功能，微服务解决方案不断发展，并基于许多最新的创新开发源码技术增加相应功能。
当然除了上述调查中所指出的挑战以外，还有——
确定需要迁移到微服务
在开始将应用程序分解为单个的微服务之前，首先需要了解它的全部范围和架构，这可能很有挑战性，需要使用更全面的视图，但是基于过时的信息，这些信息并不能反映应用程序当前的架构。
需要找到一个解决方案，帮助发现和映射应用程序的每个组件、依赖项和第三方调用，这个解决方案应该帮助了解这些片段的关系，以及它们如何影响应用的行为和用户体验，有了这些信息，就可以清楚地了解需要迁移的内容，并且能够对微服务的架构做出更明智的决定。
确保微服务满足或超过迁移前的性能
为了确保应用程序在迁移后顺利运行，而且用户体验没有受到负面影响，需要一种方法来去比较迁移前后的性能度量，这也许是一件相当困难的事情，因为这两种环境的架构（对硬件的更高和对分布式架构的迁移）可能看起来截然不同，而由独立主机提供商提供的监控工具只提供了整个框架的一小部分，无法创建更全面的数据集，这让事情变得更加困难。
为了解决这些问题，并建立一个一直的基准来衡量您的性能和用户体验，需要在开始迁移之前捕获关键用户交互（通常称为业务事务），在迁移过程中，业务事务可能保持不变，而其他指标可能会随着不同的代码路径和部署在不同的基础设施上而发生变化，使用关于业务事务的基线数据，可以轻松地比较迁移环境前后的性能，并确保对用户体验或整体性能没有影响。
监控新的微服务环境
前文已经提到监控是一大挑战，这里详细说一下，在一些硬件上运行单个代码库的单行单块应用程序，两三个工具就可以提供完整的、直接的对应用程序基础设施性能的监控，然而，随着微服务的引入，以及每个服务为技术堆栈，数据库和托管提供程序实现自己的解决方案的潜力，单个服务现在可能需要比整个应用程序更大量的监控工具，而微服务监控带来了具体的挑战：它们通常很短暂，这意味着在较长的一段时间内，监控可能会更加复杂；而且还会有更多的路径通过服务到达，会暴露出一些问题如线程争用。
最后，虽然开发团队以前不需要一个监控解决方案，但它将基础设施考虑在内，迁移到DevOps和对云原生技术的依赖意味着这个因素不能再被忽视了。
因此要找到一个统一的监控平台，并支持所有的环境，不管是语言还是技术堆栈。这个解决方案必须将来自应用程序和基础结构的度量标准整理成一个真实的来源，并允许这些指标与用户体验相关。
6、克服挑战的四大活动
各企业正在开展相应的办法以应对上面所提出来的各种挑战，受调查者认为，解决这些挑战的前四项办法是：
开发/实施内部Microservices工具
重组
与供应商专家合作/使用供应商作为受信任的顾问
采购或使用微服务平台/解决方案
受访者表示，在微服务方面，他们一直依赖供应商和供应商中小企业作为他们信任的顾问，此外，许多人回应说，重组是一种缓和活动，以克服与企业文化有关的微服务挑战，因此，要在市场上评估微服务解决方案，并选择符合要求的最佳方案，如果解决方案存在漏洞，就在内部实现这些差距，依靠供应商来适应和实施微服务，想要从企业既定流程中激发变更，可能需要重新组建团队，通常引入文化变革和重组，最好先按小的几人团队开始。
7、应用服务器可以用于微服务
因为有了Docker和Kubernetes容器作为一种实现微服务的技术取得了很大的成功。
正如前文所说，企业不只是为新项目应用微服务，也不应用于现有的应用程序，其中许多应用程序是用Java EE使用传统的应用服务器编写的，但并不是所有的应用服务器都是相同的，市场上许多应用服务器都没有实现现代化或重新设计，以满足云原生的开发需求。所以，需要用户自行辨别，选对工具。
如果拥有在Java EE和应用服务器上有着大量经验和专业知识的员工，可以让他们利用经验在现代服务器中开发微服务，保证是在一个多运行时/多技术/多框架的微服务环境中。
8、标准仍然是非常重要
对于开发微服务的客户来说，标准仍然是非常重要的事情。
Red Hat中间件客户使用或考虑使用Java EE进行微服务的三大原因如下：
Java EE是一个标准
无需再去培训员工
Java EE能够运行产品，因为它已经很好地建立了企业级优化
这表明，Red Hat中间件客户看到了开源社区驱动标准和和规范的价值，其旨在运行企业应用程序，并具有可靠性、可用性、可伸缩性和性能（RASP）功能。
想要了解更多微服务知识的，可以关注我，顺便给大家推荐一个交流学习群：650385180，里面会分享一些资深架构师录制的视频录像：有Spring，MyBatis，Netty源码分析，高并发、高性能、分布式、微服务架构的原理，JVM性能优化这些成为架构师必备的知识体系。还能领取免费的学习资源，目前受益良多，以下的课程体系图也是在群里获取。
总结：以上就是我要说的内容，希望以上的内容可以帮助到正在默默艰辛，还在迷茫或者遇到瓶疾且不知道怎么办的Java程序员们，我能帮你们的只有这么多了，希望大家在往后的工作中，一切顺利。
作者：伊竹凌
链接：https://www.jianshu.com/p/87530a6dcbf5