微服务架构被认为是构建大型复杂系统的最佳理论指导，其采用了分而治之、单一职责、关注点分离等方法论来设计系统架构。微服务的实现方式和思路有很多种，本文简述基于kubernetes的微服务平台建设思路及技术选型。
应用架构发展历史
要了解微服务架构提出的背景，首先我们来看一下应用架构的发展历程，如下图所示：
- 单体应用：传统应用的开发技术为.NET、J2EE等技术，开发完成后部署在websphere、weblogic这样的商业容器中（或者开源的tomcat）。应用间的交互一般通过CORBA、DCOM这样RPC风格的组件进行，此时并没有服务化的概念。部署的环境一般为小型机、服务器。
- SOA架构：业界在意识到了系统集成标准化的重要性后，提出了SOA的理念。SOA强调的是服务化、标准化，通过制定统一的应用接口标准，所有的应用都可以方便的提供服务，并且也可以快速调用其他应用提供的服务，通过一个集中化的服务中间件，系统集成的效率大大提高。经典的落地场景就是ESB企业服务总线。交互协议多用基于SOAP的web service。在这个时期，出现了虚拟化技术，应用可以部署在vmware虚拟机中，大大提高了资源的利用效率。
- 微服务：其实在martin fowler写那篇经典的微服务论述文章前，业界很多公司早就在实践微服务了。国外的有netflix oss技术栈，国内的有大名鼎鼎的dubbo框架。esb在落地过程中碰到了很多问题，集中化的中心节点很容易造成性能瓶颈，并可能产生单点故障，在互联网公司的实践中上千甚至上万的服务，已经不可能通过esb去承载。微服务与传统的esb区别就是去中心化，去掉了中心esb节点，取而代之的是一个分布式的服务化框架，提供服务注册、服务发现、限流熔断、配置管理等一系列高级功能。由于互联网的流行，此时的交互协议多为轻量级的RESTful风格协议。这个时期，是云计算真正落地的时期，以aws为代表的Iaas技术大行其道，从根本上改变了应用部署的方式。（事实上，netflix就是基于亚马逊的EC2弹性节点来动态的增加、减少微服务实例的，应用架构的灵活性大大增加）
- 云原生：云原生其实就是微服务的一种落地，但我认为，云原生已经可以看作是下一代的应用架构了。它从平台层面重新审视整个微服务实施中的关注点，并且以宏观视角给出了完整的解决方案，强调与devops的整合，整体抽象层次最高，且做到了语言无关，这是上一代微服务所做不到的。需要注意的是，在云原生时代，应用和基础架构需要进行深度集成，换句话说，只有你在kubernetes这样的云基础设施上部署的应用，才可以算成是“云原生”应用。应用充分利用了基础架构的能力（微服务能力），这才是“云
扫一扫
2104
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
