引言
Martin的一篇文章似乎点燃了微服务架构的引擎，从此国内外无论是哪个互联网开发团队，似乎使用微服务架构已然成为标配。介于网上介绍微服务的文章或书籍实在太多了，本文将结合作者的学习、从业经验对微服务架构的未来做一些不同角度的解释，权当抛砖引玉。
从宏观的角度来看，微服务发展的本质在于：
一、物理单机无法支撑越来越大规模的应用，无论从物理能力上和经济性角度来看都到达难以为继之境。
二、系统规模指数级上升，传统的软件工程方法与低交付周期限制下的敏捷、Devops、持续集成、持续交付加快了微服务的蓬勃发展。
三、从集群的角度来看，单体应用与微服务并无区别，都是对外提供服务的一个整体系统。但在微观角度来看就大有不同了。比如：微服务架构具有更好的伸缩性、更高的性能、更强的扩展性。
无论你用Dubbo还是Spring Cloud或者是自研的微服务框架，对于开发人员而言，还是需要对诸如网络、服务发现、服务追踪、服务治理、服务熔断、RPC底层实现等细节技术有相当的了解，才有可能实施微服务方案。而在单体应用时代，开发人员对底层的了解甚至可以是透明的。比如，不了解线程与线程之间如何交换数据（底层实现）并不妨碍你实现系统。所以可以说，当今的微服务架构并不完美，一个完美的实现是不需要开发者了解太多细节的。
抛开上述的说的“太多细节”以外，微服务还剩下什么呢？重中之重就是服务的拆分！遗憾的是我看过的书和文章中基本没有涉及到服务拆分环节的知识。一来因为服务拆分与业务结合的比较紧密；二来因为服务拆分 与传统的业务建模有差很紧密的关系，难于掌握。
从CAP角度看无论是传统的CP，还是分布式时代常见的AP，从整体上来看，从整个大跨度时间上来看，其实是一致的。而在现阶段我们却要为此付出不菲的代价。如使用阿里的Oceanbase数据库、使用最终一致性方案或业务妥协使用TCC方案等。一个完美的微服务架构自然也不需要开发者了解太多的分布式事务细节，就像你使用Mysql时不需要了解它的事务实现细节是如何实现的，是写binlog?还是在内存上做的？并不影响你业务层面的开发。
再让我们看看“服务追踪”，一个典型的服务追踪实现是通过一个惟一的traceId，在调用链中传递，当然还会辅于spanId，通过这两个ID可以完整展示整个调用链上的耗时、结果等。而在单体架构中，方法间你调用，你无需知晓细节，那现在“服务追踪”的实现是不是只是过渡阶段呢？
最后让我们看看从物理机到虚拟机、再到Docker，集群的角度上来看是硬件利用率的提升，单机的角度看，进程间的通信也从单机内部变成了集群内部。很难相像当系统拆分得成很多微服务时，不用k8s、不用docker，使用传统的运维手段会是什么样的一个场景？
似乎这些中间层技术可能会涉及到不同厂商之间利益博弈。但在技术领域，最终，行业标准总是会出来的，未来的Service Mesh会成为事实的标准吗？让我们拭目以待。在这些行业标准出来之前就只有八仙过海，各显神通了。
综上，一个完美的微服务架构是不需要开发人员对集群内应用细节有太多技术细节的关注的，未来开发人员应该将更多的精力放在服务拆分上。那现阶段我是不是应该不学你所说的“细节知识”了呢？也不是，当大家都在使用胶片相机的时代，在数码时代来临前，大多数照相机的生产商都只能使用胶片。这时，如果你的胶片质量实在太差，可能让你现在就失去了市场。但是，如果你还将太多的时间花在胶片上，而不是镜片上，那可能就是用错方向了。