前言
既然系统采用了微服务架构，就需要了解一些微服务的特性，这样在进行微服务开发时，脑海中才会有一些指导方向。微服务具有以下特性。
1. 服务组件化
组件是独立、可替换、可升级的软件的单元。将整体应用拆分成独立的服务组件后，当对单个组件的修改完成后，只需要重新部署该组件即可。这也不是绝对的，有一些改动会影响服务间的接口，调用方（消费者）也需要进行相应的修改与部署。所以好的微服务架构的目标是通过高内聚、低耦合来尽量减少不同服务之间的依赖。
2．围绕业务能力组织团队
康威定律指出：设计系统的架构，受制于产生这些设计的组织的沟通结构。不同公司的产品结构，基本上反映了组织的沟通结构，如图1-3所示。
在一个单体应用中，一个项目会有很多研发团队的人参与，如前端工程师组、后端工程师组、数据库管理员组，不同组的人参与同一个项目，彼此沟通成本很高。单体项目的分工图如图1-4所示。
在微服务项目中，团队是围绕业务来进行组织的。例如，某个服务组里有前端工程、后端工程师、数据库管理员，这算是一个工作单元，能极大降低沟通成本。
3. 产品不是项目
在大部分软件开发时，采用的都是项目的形式，开发团队开发完软件后将软件交给运维团队去维护，原来的项目团队解散。微服务支持者倾向于避免这种模式，他们认为团队应该在产品的整个生命周期内对它负责。这就是 Amazon（亚马逊）提出的“you build，you run it”。这么做的好处是可以让开发人员经常接触到他们的产品，从而了解产品在生产中的行为，并增加与用户的联系，同时在业务升级时也很方便，毕竟开发和升级都是由同一个团队负责。
4. 去中心化的数据管理
在单体应用中，数据都在一个数据库（这里指的是逻辑库，可能物理上部署多个数据库服务器）中，管理难度大。在微服务中，不同的业务数据是放到不同的服务所对应的数据库中的。
如订单存放到订单库、商品存放到商品库等，从而大大降低了数据的管理难度。去中心化数据库示例如图1-5所示。
5. 分散治理
由于將大服务分成了小服务，所以每个服务都可以根据自己的需求，采用合适的技术实现方案，如采用不同的语言（有的业务适合用Go，有的业务适合用Java）、采用不同的存储(有的业务适合用Redis，有的业务适合用MySQL）等。这样更利于提高开发效率，节省资源。
总结
了解了微服务的特性，作为一名有着架构师梦想的程序员，应该清楚地认识到微服务可以给实际工作带来的好处。
- 从公司团队管理角度。将服务拆分成微服务后，可以让独立的团队完成独立的服务，实现不同的业务，使得团队更聚焦，減少了跨部门沟通的障碍，大大提高了开发效率。
- 从公司产品研发角度。由于服务彼此独立，可以针对不同的产品需求，针对不同的服务快速地进行产品升级。从而在快节奏的软件开发环境中，缩短对市场的响应时间，加快产品的迭代。
