1.1　微服务面临的挑战

微服务的粒度影响服务的交付速度及扩展性，微服务的开发引入治理组件，增加了开发的难度，以容器为基础的微服务基础设施在弹性等方面仍有不足，而微服务增加带来的基础设施成本也是微服务实施的新挑战。

1. 微服务的粒度仍然比较大

当前微服务划分主要遵循单一职责的原则，比如将用户管理的功能作为一个单独的微服务。如图1-1所示，用户管理微服务提供了API注册、登录、登出功能。通常，从提升用户体验的角度来看，浏览器会保留用户的会话，除非用户主动登出，否则不会请求登出API。所以，登出和注册的QPS差距较大，对扩展的诉求完全不同。而且，注册API和登出API的变更频率也可能不同。进一步拆分可以带来扩展性等便利，但整个微服务的数量也会提升一个量级，给基础设施的管理带来负担，那么如何做好架构权衡，既能够拥有架构上的高可扩展性，又不用增加基础设施管理成本呢？

图1-1　用户管理微服务

2. 微服务开发仍有较高门槛

如图1-2所示，Java微服务开发的软件栈要求开发者掌握以下技能。

图1-2　Java微服务开发技术栈

相比于单体应用开发，微服务开发效率得到提升的部分来自服务粒度减少及开发框架的改进，例如，从复杂的SpringMVC演进到SpringBoot，框架更加轻量化。但在其他方面（并发处理等）并没有什么改变，同时在微服务治理、分布式事务等方面的开发难度反而增加了。服务网格的出现，让开发人员可以不用关心服务治理的内容，但这样会带来服务性能的下降和维护的复杂性，其使用的范围也存在局限。是否存在一种新的编程模型及开发框架，让开发者在了解基本的语言特性和编程模型后，便可上手开发业务逻辑，而不用关心网络、并发、服务治理等问题？

3. 微服务基础设施管理、高可用和弹性仍然很难保证

容器和Kubernetes工具的使用，提升了应用部署及基础设施运维自动化的能力，但保证基础设施高可用、可扩展对运维人员的能力要求很高。如图1-3所示，服务上云后，基础设施团队可以不用再关心服务器、交换机等硬件的运维，但仍然需要关心虚拟机的维护，如安全补丁、基础镜像的更新升级、扩容等。

图1-3　基础设施团队依然需要管理虚拟机

从On-Premise到公有云，实际上虚拟机的可用性在降低，比如云服务商提供的单虚拟机的可用性可能只有95%。运维人员需要借助云侧的工具来保证基础设施的高可用，难度仍然存在，而且很依赖运维人员的能力。

集群及其他云原生工具的维护也带来额外的挑战。以Kubernetes集群为例，维护和管理Kubernetes集群需要专业的技能。同理，维护云原生的监控、日志服务的高可用性也有不小的难度。所以，基础设施管理的难度仍然存在，只是从虚拟机转移到容器集群，从Rsyslog转移到ElasticSearch。

对于服务层面的扩展性，当前的策略也比较简单，例如，设定最少和最多使用的虚拟机数量，或者想办法改善根据CPU/内存使用率来伸缩或扩容的延迟。但是，由于总体资源量不会超过策略设定的虚拟机极限数量，因此一旦请求超过最大资源能承载的范围，可能会影响用户的使用体验甚至会服务中断。以容器为单位的扩容，从虚拟机性能的分钟级减少到30s左右，但当面对突发流量时依然会出现响应不及时、用户体验差的情况。是否存在全托管的基础设施及监控运维服务，能提供更好的弹性，从而让开发者无须关心所有底层和集群的维护工作，不再依赖高级运维人员来保证基础设施的可用性？

4. 基础设施的成本依然较高

微服务会增加基础设施的成本。每个微服务都要考虑冗余，保证高可用。随着微服务数量的增加，基础设施的数量会呈现指数级增长，但云服务的基础设施收费方式没有改变，依然采用按照资源大小及以小时为单位（或包年）计费的方式。闲时和忙时的收费相同，对企业来说存在成本的浪费。是否存在一种新的基础设施服务，能按照“用多少付多少”的方式收费，从而降低基础设施成本？

微服务面临的这些新问题，是否可以通过新的基础设施服务及开发模式来解决呢？