## 面向服务化架构(SOA)
在分布式架构下，当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心对集群进行实时管理。此时，用于资源调度和治理中心(SOA Service Oriented Architecture，面向服务的架构)是关键。
**优点**
- 使用注册中心解决了服务间调用关系的自动调节
**缺点**
- 服务间会有依赖关系，一旦某个环节出错会影响较大( 服务雪崩 )
- 服务关心复杂，运维、测试部署困难
## 微服务架构(Micro Service)
微服务架构在某种程度上是面向服务的架构SOA继续发展的下一步，它更加强调服务的"彻底拆分"。
**优点**
- 更好的开发规模
- 更快的开发速度
- 支持迭代开发或现代化增量开发
- 充分利用现代软件开发生态系统的优势（云、容器、 DevOps、Serverless）
- 支持水平缩放和细粒度缩放
- 小体量，较低了开发人员的认知复杂性
**缺点**
- 更高数量级的活动组件（服务、数据库、进程、容器、框架）
- 复杂性从代码转移到基础设施
- RPC 调用和网络通信的大量增加
- 整个系统的安全性管理更具有挑战性
- 整个系统的设计变得更加困难
- 引入了分布式系统的复杂性
### 微服务定义
- **一组小的服务**
原来的单块服务都是业务能力大而全的打包在一个单块中，微服务主张把这些单块服务进行拆分，形成一个个小的独立的服务。这里有个最大的特点是“小”，那么纠结要小到什么程度才为之小，很多同学都会纠结这个小的点，因为这个小并没有特别和明确的规定，所以这也就引申出了现在很多DDD领域驱动设计来指引微服务的拆分，但基本上一个微服务能让一个开发人员能够独立的理解，基本上就称为一个微服务，具体有多少行代码并不是很关键。
- **独立的进程**
微服务是运行在独立的进程当中，例如java程序部署在tomcat，也可以部署在容器docker中，容易本身也是一种进程，所以微服务可以以进程的方式去扩展。
- **轻量级的通讯**
微服务主张使用轻量级去构建通讯机制，例如http，固定消息格式和减少消息格式，服务之间不耦合，让通讯尽量轻量。
- **基于业务能力**
微服务是基于业务能力进行构建，例如有用户服务，登陆服务，商品服务，基于这些业务能力去构建这些微服务。
- **独立部署**
微服务被拆分开后，每个团队独立维护自己的微服务，开发，迭代自己的微服务，是可以独立的去部署，团队之间是不需要特别的去协调，这些对业务开发维护可以做到更加的敏捷，轻量，快速。
- **无集中式管理**
原来单体服务是需要整个技术团队是需要独立的架构团队去管理，统一架构，统一技术栈，统一存储，微服务就不太一样，微服务主张每个团队根据自己的技术需要，选择自己最熟悉，最高效解决问题的技术栈，甚至选择不同存储方式。
### 康威定律
> 康威法则设计系统的组织，其产生的设计和架构，等价组织的组织架构
**单块应用时代**
几个团队共同去对一个单块应用去开发和维护时，如果一个团队对这个单块应用进行改造引入一些新的功能或技术的时候，往往需要其他的团队协作和配合，连同做集成测试才能交付这个应用，这个时候，不仅仅是沟通协调成本高，团队和团队之间往往容易产生摩擦。**也就是说，多团队之间和单应用产生不匹配，违反康威法则**。怎么解决，微服务是一个解决的手段：
我们把单块的应用拆分成诺干个独立的应用，每个团队负责自己的服务，相互之间不干扰，当团队A服务的服务进行修改不需要其他的团队来配合，或者说这种配合沟通成本比较少，一般只发生在双方边界交集的地方，那么这个时候发现多团队和微服务之间架构的关系可以映射起来，它符合了康威法则，整体研发效率更高效。
### 微服务利弊
- **利**
- **强模块化边界**
我们知道做软件架构，软件设计，模块化是非常重要的一点，一开始我们写程序做软件，我们采用类的方式来做模块化，后面开始采用组件或类库的方式做模块化，可以做到工程上的重用和分享给其他团队来使用。微服务在组件的层次上面又高了一层，以服务的方式来做模块化，每个团队独立开始和维护自己的服务，有明显的一个边界，开发完一个服务其他团队可以直接调用这个服务，不需要像组件通过jar或源码的方式去进行分享，所以微服务的边界是比较清晰的。
- **可独立部署**
可独立部署是微服务最显著的一个特性，每个团队可以根据自己的业务需求，当产品经理或业务方把需求提过来，可以根据需要独立开发和部署服务，一般来说不需要太过依赖其他团队去协同，这个对比单块应用，单块引用在这个方面需求很多团队来协助和帮忙。
- **技术多样性**
微服务是分散式治理，没有集中治理，每个团队可以根据团队自己的实际情况和业务的实际情况去选择适合自己的技术栈，有些团队可能擅长Java开发，有些团队可能更偏向前端，更适合用nodejs去开发服务，不过这个不是越多越好，技术栈的引入也是有成本
- **弊**
- **分布式复杂性**
在原来单块应用就是一个应用，一个对单块应用的架构比较熟悉的人可以对整个单块应用有一个很好的把控。但是到了分布式系统，微服务化了以后可能涉及到的服务有好几十个，一些大公司可能涉及到的服务上百个，服务与服务之间是通过相互沟通来实现业务，那么这个时候整个系统就变成非常复杂，一般的开发人员或一个团队都无法理解整个系统是如何工作的，这个就是分布式带来的复杂性。
- **最终一致性**
微服务的数据是分散式治理的，每个团队都有自己的数据源和数据拷贝，比方说团队A有订单数据，B团队也有订单数据，团队A修改了订单数据是否应该同步给团队B的数据呢，这里就涉及到数据一致性问题，如果没有很好的解决一致性问题，就可能造成数据的不一致，这个在业务上是不可以接受的。
- **运维复杂性**
以往的运维需要管理的是机器+单块的应用，分布式系统和单块应用不一样的是，分布式系统需要很多的服务，服务与服务之间相互协同，那么对分布式系统的资源，容量规划，对监控，对整个系统的可靠性稳定性都非常具备挑战的。
- **测试复杂性**
对测试人员来说，在单块应用上，一个测试团队只需要测试一个单块应用就可以了，到了分布式系统，各个服务是分布在各个团队的，这个对测试团队来说要求就很好，做集成测试的时候需要很多的团队相互配合去联合做集成测试。
