微服务与软件架构师，以及微服务架构应用具备的特性

微服务架构（Microservice Architecture）是一种架构概念，旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦。你可以将其看作是在架构层次而非获取服务的类上应用很多SOLID原则。微服务架构是个很有趣的概念，它的主要作用是将功能分解到离散的各个服务当中，从而降低系统的耦合性，并提供更加灵活的服务支持。

今天看来，传统的软件开发（尤其是应用型软件开发）其实是相对简单的。软件运行在基本可靠的单机环境下：CPU 提供计算能力，内存提供动态存储，总线提供数据传输，硬盘提供永久存储。这些概念稳定而直观，程序员要完成的，就是调用和组装编程语言提供的各种功能，来满足现实的需求。相比应用程序员良莠不齐的开发水平，无论是操作系统还是硬件环境，都是来自大公司的工业级别的产品，是值得信赖的。

如果把程序要完成的功能比作个人，软件运行的环境比作房屋，那么房屋虽小，却是值得信赖的。对个人来说，只要进去了房屋里，就有相对稳定的环境，相比野外生存就是巨大的进步。当然，如果遇到意外情况，在野外可能生存机会大一点，在房屋里只能与房子“一损俱损”了。

微服务架构有以下的一些通用特性，但并非所有微服务架构应用都必须具备所有这些特性：

通过服务实现应用的组件化(Componentizationvia Services)：微服务架构中将组件定义为可被独立替换和升级的软件单元，在应用架构设计中通过将整体应用切分成可独立部署及升级的微服务方式进行组件化设计。

围绕业务能力组织服务(Organizedaround Business Capabilities)：微服务架构采取以业务能力为出发点组织服务的策略，因此微服务团队的组织结构必须是跨功能的（如：既管应用，也管数据库）、强搭配的DevOps开发运维一体化团队，通常这些团队不会太大（如：亚马逊的“Two pizzateam”- 不超过12人）。

产品而非项目模式(Productsnot Projects)：传统的应用模式是一个团队以项目模式开发完整的应用，开发完成后就交付给运维团队负责维护；微服务架构则倡导一个团队应该如开发产品般负责一个“微服务”完整的生命周期，倡导“谁开发，谁运营”的开发运维一体化方法。