最近这些年，微服务非常火，那你有没想过微服务的动机是什么？其实，最重要的动机就是业务变化太快了。特别是移动互联网出现以后，各种各样的业务：共享单车、支付宝、微信支付等等，业务经历着飞速的变革与创新，所以就要求底层的应用技术能够支撑得上业务的快速变化。
我们看一下应用架构的变迁，其实也是从另一个角度来印证上文说的“快”。
第一代是单体架构，当然它有很多，例如紧耦合、封闭架构等各种各样的问题。第二代是SOA架构，可能大型企业级的应用里面会比较多，提供了很多种支持，实际上我们看到SOA架构的时候，它已经强调松耦合了。那么他强调这一点是为了什么？其中一点就是因为快（当然不是仅仅为了快）。到现在第三代微服务架构，它实际上是变得更加灵活了。在业务变化非常快速的背景之下，微服务架构是一个非常好的解决方案，微服务的核心——敏捷、灵活、精准弹性。微服务架构出现的最大的意义是不断地提高交付效率，缩短交付周期。
微服务最有名的人——Martin Fowler，在2015年提出了微服务的概念（实际上2009年Netflix就已经开始实践微服务了，但是当时没有微服务一词）。2015年Martin Fowler明确的提出了微服务的概念并对它进行了一些比较清晰的定义，最主要的就是：小、独、轻、松。就是说微服务要小，模块边界要更清晰，支持独立部署独立演进，每个微服务都应该可以独立部署，独立演进，独立升级的。另外允许技术多样性，就是在微服务构成的一个整体的应用系统里面，每一块的业务要用你最适合的技术去实现，而不是都统一用一种语言去实现，这也是微服务非常重要的一个特点。
所有事情都有两面性，那微服务也不是只有好处没有坏处的，它也会带来问题。其实很明显，例如，从运维人员的角度来看，原来只需要运维一个应用；把它拆开后，就需要运维多个应用，复杂性和难度一定是增加的。从开发人员的角度来看，原来写程序的时候，单体应用，方法之间的调用就可以解决很多业务的处理了；变成分布式以后，就要远程调用，不能用简单的进程内的调用了。用远程调用它就会出现一些问题，比如会变慢、可靠性比进程内部的差等等。那开发人员就要去处理这些问题，要去为这些问题做准备。还有一点也是非常重要的，就是数据一致性的问题。原来在单体应用里面，可以用数据库保持数据的一致性（或者说用数据库的事务去保证数据的一致性）；但是到分布式系统以后，突然发现这种方式不行了。因为在微服务架构里面提倡的是数据分开，就是说每一个微服务都会有自己独立的数据库。Martin Fowler也讲了允许技术的多样性，到数据这一层也要用最合适的数据库技术去构建单独的微服务。原来保证数据一致性都是关系型数据库，直接用事物就好了。但是到了微服务就不一样，可能有些微服务用的是关系型数据库，但有些微服务用的是非关系型的数据库。所以在这样的前提下，去保证整个系统的数据一致性，也是带来了很大的挑战的。
以上大致介绍了什么是微服务架构，它有什么样的特点，又有什么样的优势和挑战。想了解更多微服务相关内容吗，华为云学院（https://edu.huaweicloud.com/）
已上线多门微服务相关课程，从基础知识入门，到开发第一个微服务，到微服务的上线、治理，带你一站式攻克微服务，敏捷开发微服务应用，快来报名学习吧。
原文地址：http://blog.51cto.com/14042634/2314053