郭理靖，十二年互联网、六年云计算行业开发经验，曾是云服务开发者，现在是各类云服务的深度使用者，曾任北京同仁堂国际 CTO、京东云平台高级总监。曾在金山、淘宝、盛大就职。目前担任北京简网 CTO，负责产品与技术部门。
架构模式演进
CGI 模式
图 1
CGI 出现于 1993 年，图 1 是 CGI 模式比较简单的结构图。
MVC 模式
开源电商软件等都是采用 MVC 模式，MVC 模式是做软件开发必学和必经历的一个阶段。
图 2
1970 年提出了 MVC 的概念，当时的主机和客户端早已凸显了这个概念。如图 2 所示，这是一个 MVC 模式的标准框架，做一个电商网站时，会把订单、用户、物流信息整合起来，做一个单体服务。
90 年代正是 Java 的时代，MVC 模式在这个时期开始变火。开发者把 MVC 的实践引入 Java 世界。这个模式大放异彩后，各种语言都在借鉴。
SOA 模式
图 3
单体服务之后是 SOA 标准化(图 3 )，在 SOA 里面比较重要的是 Service bus。在企业架构里它起到很关键的作用，主要用来沟通各个服务组件，就像高速公路一样，用来连接所有的村庄。
经过 MVC 模式后，单体模式开发速度很快，网民的速度增长也很快，服务器接收的请求越来越多，慢慢需要做拆分才出现了 SOA 概念。虽然 1983 年提出了 SOA 的概念，但国内绝大部分企业至少是在 2000 年之后才开始 SOA 化。
Microservices 模式
图 4
图 4 是 Microservices 的架构图，每个 Host 里面都有一个服务，它是独立的。Microservices 于 2005 年出现，到现在仍备受关注和讨论。一个概念由提出到落地，有很深层次的原因，具体后文分析。
何时使用微服务?
图 5
微服务并不能解决所有问题，所以一定要慎重考虑何时采用微服务。这张图(图 5 )很常见，单体服务的开发速度、代价都是比较低的，只有业务复杂到一定程度的时候才适合采用微服务。微服务其实是一个理念和框架，它对团队的要求比较高，首先团队所有成员都要认可这个事情，认可微服务的理念和治理框架，否则执行过程中会有很多问题。
图 6
单体服务是把所有东西都部署在一块，如图 6 所示，这是最简单的单体服务。在一定阶段下，简单代表高效，所有东西部署在一起时，整个过程的沟通效率会提高。
提到微服务时首先会提到康威定律，即当开发一个新的架构时，组织架构图跟软件架构图是极其相似的。举例说明，一个最简单的 APP 开发架构包括移动端和服务端，如果把后台服务的人进行角色分层，会有运维、前端、做中间商业逻辑的后台开发者，就会发现软件架构跟组织架构很相似。对微服务进行的拆分，其实也是对人员组织架构和角色职能的拆分。这两者是很相似的。
为什么 API 很重要?
微服务里面最重要的是 API ，API 是服务公开化的方法，它是服务价值的精华体现。API 一定要可靠、可用、可读，前两点大部分人都能做到，但是可读性，很多团队却做得很差。许多国内开发出来的开发系统文档可读性很差，看完之后可能还需要跟对方人员沟通。然而，无论是给内部开发，还是给外部用户提供服务，都不希望产生更多的沟通。
出现这种情况的原因在于程序员本身的特性，程序员是写程序的。很多程序员认为写文档不如写程序有快感，这对于很多人来说是一种挑战，也是一件很枯燥的事情。可是，对于公众来说，文档却很重要，就像要成为一个好的架构师就要有良好的沟通能力，要做好微服务，API 可读性很重要。