微服务第一讲
什么是微服务
微服务的概念定义没有特别官方的统一语言，参考Chris Richardson的《MicroServicesPatterns》一书中的定义：把应用程序功能性分解为一组服务的架构风格。
这个概念是通过MartinAbbott和Michael Fisher的名著《The Art of Scalability》中描述的三位可扩展模型（扩展立方体）而来。
X轴扩展：在多个实例之间实现请求的负载均衡。可以简单理解通过负载均衡对某个应用实现水平扩容。
Y轴扩展：根据功能把应用拆分为服务。也就是单体应用到微服务的演变。
Z轴扩展：根据请求的属性路由请求。可以简单理解为路由网关，根据不同的纬度将交易路由到指定的应用服务上。
X轴和Z轴扩展有效地提升了应用的吞吐量和可用性，Y轴扩展解决了单体炼狱问题。优点 | 缺点 | |
单体服务 | 应用开发简单 | 过度臃肿造成复杂性升高（脏泥球理论） |
易于对应用程序进行大规模的更改 | 开发速度慢，交付周期变长 | |
测试相对简单直观 | 很难保证交付质量 | |
部署简单明了 | 难以扩展（主要是基础资源层面） | |
横向扩容成本较低(加一层负载均衡) | 需要长期依赖某个可能已经过时的技术栈 | |
微服务 | 使大型的复杂应用程序可以持续交付和持续部署 | 服务的拆分和定义是一项挑战。(可以根据DDD或者业务功能拆分) |
每个服务都相对较小并容易维护 | 分布式系统带来的各种复杂性，使开发、测试和部署变得更困难 | |
服务可以独立部署 | 当部署跨越多个服务的功能时需要谨慎地协调更多开发团队（变更管理） | |
服务可以独立扩展（硬件资源） | 开发者需要思考到底应该在应用的什么阶段使用微服务架构 | |
微服务架构可以实现团队自治 | ||
更容易实验和采纳新的技术 | ||
更好的容错性（故障隔离） |
持续交付需要有DevOps配套支持，持续交付部署可以为业务带来若干价值：缩短了产品的上市时间，使企业能够快速响应客户的反馈；使企业能够提供当前客户所期望的可靠服务（即业务连续性保障）；员工满意度更高，因为开发人员可以因此花费更多时间来提供有价值的功能，而不是四处担任救火队员。什么是SOA
面向服务的架构（SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）进行拆分，并通过这些服务之间定义良好的接口和协议联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。
对比
SOA | 微服务 | |
服务间通信 | 智能管道，例如Enterprise Service Bus(ESB也叫企业服务总线)，往往采用重量级协议，例如SOAP或其他WS*标准 | 使用哑管道，例如消息代理，或者服务之间点对点通信，使用轻量级协议，例如REST或gRPC |
数据管理 | 全局数据模型并共享数据库 | 每个服务都有自己的数据模型和数据库 |
典型服务的规模 | 较大的单体应用 | 较小的服务 |
总结
SOA和微服务的设计思想本质上是一致的，但是在具体实现上存在较大差役。SOA的技术栈通常都比较重，其主要原因也是因为它出现的年代比较早，当时的技术方案还比较落后。其次在数据管理层面也可以看出对于数据模型和共享上与微服务存在本质区别，SOA更注重的是应用拆分和管道管理，对于数据管理没有投入足够的性能或者业务连续性方面的考虑。再有就是SOA的应用往往还是比较大的，冗余程度要高于微服务，所带来的好处就是规避了很多服务治理方面的问题。我们在设计微服务架构时，很容易由于服务拆分的不好导致最终形成类似SOA这种架构。