我认识的微服务

最近在做一些分享，我选择了架构方面的知识，团队也想补充一些这方面的知识，看来看去就选择了微服务，这个看起来陌生其实很熟悉的东西。

为了准备这次分享，我翻看了很多的微服务方面的文章，也购买个几本关于微服务架构的书，逐渐对微服务的架构有了较清晰认识，分享结束后就趁热赶紧写下自己对微服务的理解，只是本人对于微服务的理解，如有不对的地方欢迎更正。

首先说下微服务的概念，这个概念是Martin Fowler提出的，我认为这个概念提的很好，把这几年互联网所用的知识进行了总结，并给出了一个很高大上的名字微服务，这点不得不佩服老外，为什么技术上的一些重要理论和概念都是外国人提出的，国内平时那些牛哄哄的人去哪里了？为什我认为微服务是对过去技术的总结而不是新技术新思想新架构，因为在这个概念提出之前我们就是这么做的，如果不信那就接着往下看，我慢慢道来。

说到服务，SOA肯定是绕不过去的，SOA从2000年左右提出到现在已走过10几个年头了，从最初的大家的眼睛一亮，到逐渐冷静对待，以至于到最后到处挑刺和嫌弃，过程还是比较清晰的。我接触SOA算是比较早的，那时候刚出道，这东西对我来说感觉很遥远，看的云里雾里，只是了解一些基础知识，直到2009年左右一个技术支持类的项目（一个平台要支持移动客户端，在不改变业务逻辑的情况下，只能通过开放服务实现）落在自己头上，才真正开始了SOA的实践。

我的理解，SOA的提出极大的方便了系统间的集成，尤其是异构系统的集成，尤其是对于企业内应用或则企业间应用的集成，起到了很大的作用；我前几年一直从事的就是企业级系统的开发，那时候有很多的论文研究怎样消除企业信息孤岛，实现企业内部系统间的集成并实现信息共享，SOA和ESB的出现无疑为企业指明了一个方向，原来这才是我要的。SOA的出现给传统的信息化产业带来新的概念，不再是各自独立的架构形式，能够轻松的互相联系组合共享信息。企业级应用对于协议的要求比较严格，必须一板一眼的按照规范来做，所以SOA有很多的规范，有自己独有的协议语言-WSDL ，UDDI，通讯协议SOAP等；虽然规范很多，但是使用起来也很方便，有很多的成熟工具支持将一个普通的类开放为Web Service,并且可以很方便的生成各种语言的Client程序，就连比较晦涩的分布式事务都有很好的解决方法和方案，刚开始接触SOA的时候,一些概念和技术确实晦涩和难以理解，但是等你做过一个项目并熟悉以后，感觉就完全不一样，其带来的成果真的非常明显，并且好多语言都可以很好的支持WSDL的序列化和反序列化，这位异构系统间的集成提供了极大的遍历性。从架构上讲，SOA使我们考虑问题的层次更高、粒度更大，不再局限于对象、组件和接口，而是面向服务，这一点非常重要，因为我们在处理分布式系统的时候的很多的概念和思想都来源于SOA的思想。现在有些人将SOA说的一无是处，其实是没有充分认识SOA,或则就不熟悉SOA, SOA的出现是计算机信息化方面的一个重大变革。

我们再来谈一下微服务，有很多的文章在介绍微服务的概念和模式，但是综合起来看有两种观点：

第一种观点：认为微服务是一种全新的理念和架构，与SOA有着较大的区别，是面向互联网的轻量级的架构，所以具有很好的灵活性，并且列出了一系列的特征以显示微服务的特殊性，比如面向服务与微服务架构；

第二种观念：认为这是在翻炒概念，微服务与SOA有着很大的相似性，可以说是在新时期SOA思想的演化，是为了适应互联网的需求，比如文章微服务与SOA通过比较说明了微服务与SOA的相同和不同。

我个人比较偏向于后者，我认为那些认为微服务架构与SOA有着很大区别的人可能没有真正理解SOA的思想或者没有深入了解过SOA,不仅如此，我认为微服务所提出的架构思想不是凭空创造出的一种新的思想和模式，微服务是对过去和现在的分布式框架思想的一种总结；我们过去一说到的大访问量、大数据量网站或平台，分布式框架是少不了的，这样的文章和书籍也是多如牛毛，分布式架构和技术我们很熟悉，也一直在使用：比如系统拆分、协同开发、小团队、API网关、轻量级协议(RESTFUL)、持续集成、持续交付、监控平台等，在任何一个上规模的互联网团队中，日常工作就是围绕这些开展的。

我们就微服务中心提到的一些知识点进行分析：
通过服务实现组件化：就我熟悉的电商平台来说，用户管理、产品管理是最早实现组件化并服务化的，没错我们称之为服务化；因为这些功能在系统中被频繁的使用，相对又是比较独立的，很容易以服务的方式提供。
围绕业务能力进行组织：这个就更不用说了，用户团队、订单团队、商品团队、促销团队等就是很好的体现。
基于产品而不是项目：我们做的就是产品，比如我维护这订单管理从页面前端到后端所有功能，从B端到C端所有功能，虽然订单系统不是一个独立的产品，但是它确实按照产品的开发思想来做的。
去中心化的治理：在比较大的流量的网站或平台，中心化很容易造成热点，所以从一开始就是以分布式的概念来处理这些问题，尽量减少各个系统间的依赖关系。比如订单流程的管理，如果采用中心化的流程引擎进行管理，那么 流程引擎就成为性能瓶颈，因为订单流程很长，每次状态变迁都要通过引擎处理将对引擎造成很大的压力，可以通过多机策略提高处理能力，但又为引擎数据的同步埋下了炸弹；这种情况采用协同的方式是最好的，每个任务不仅自己清楚自己做什么，还要清楚自己的下一个节点是谁，并负责向其发送消息；我认为这就是去中心化的策略。
对于基础设施自动化、Design for failure这些就更不用说了。

也许我对微服务的理解还不是很到位，到目前为止我认为微服务架构的思想是对过去这几年分布式架构，尤其是对互联网架构思想的一次理论总结和升华。微服务作为一种架构思想还需要发展和完善，可以更多的引入软件工程的思想比如持续集成和持续交付等，来提高整个产品生命周期的效率。