服务化架构：一种架构风格，即微服务架构。
1.单个服务尽量专注一件事情，高内聚、低耦合；
2.进程隔离；
3.每个服务可以独立开发、测试、构建、部署；
4.小且灵活；
微服务架构特征：
- 系统由多个服务组成，每个服务有明确的边界；
- 服务独立开发、编译、部署、测试、发布，有独立工程、独立版本、接口契约化，进程隔离；
- 由一个10人以下团队全生命周期负责，团队的目标负责产品的全生命周期，而不是负责一个短期的项目；
- 技术中立，不要求服务的编程语言统一。不同服务可以采用不同的编程语言实现，有利于逐步引入新技术。
- 智能服务端点和轻量级高性能通信机制。服务开发框架内置服务基本功能，如日志、度量、数据访问、输入校验、权限等，使得开发人员可以聚焦于业务服务的业务逻辑代码开发，降低了服务开发的门槛。
- 服务无状态，服务自动弹性伸缩。服务的无状态通过业务逻辑与数据分离，数据、会话保存在DB、Cache、对象存储等服务来实现；服务实例按需进行伸缩。
- 服务数据去中心化。每个服务拥有自己的数据库，服务不能直接访问其它服务的数据库，只能通过服务接口方案其它服务的数据。
- 服务去中心化治理。服务支持多版本并存、灰度发布、依赖关系管理、调用链分析快速故障定界。
- Design for failure。任意服务节点失效、网络闪断等故障不影响业务正常运行。
- 重用、组合已有的服务实现新的业务功能服务。业务应用在实现功能时，会调用已有的服务，如Cache、MQ、IAM等公共服务，实现自己的业务功能。
微服务带来的好处和挑战
好处：
- 服务模块的边界更清晰：微服务强调模块化结果（REST接口调用），这对大型团队非常重要。
- 支持独立不是：简单服务更易部署，由于服务是自治的，出现问题之后不会引起系统崩溃。
- 运行技术多样性：有了微服务，你可以混合使用多种语言、开发框架和数据存储技术。
挑战：
- 分布式变成难度大有风险：分布式变成难度更大，远程调用更慢且总存在失败风险。
- 需处理分布式系统的一致性：对于分布式系统来说，保持一致性非常困难，意味着大家都要处理最终一致性。
- 增加运维复杂性：需要一个成熟的运维团队（机制）来管理大量需要频繁部署的服务。