微服务架构
- 什么是微服务架构（What）
微服务架构并非是一个独立存在的概念，建议与传统的单体式（Monolithic）架构进行对比分析。相较于单体式架构将一个完整的应用（如订单系统、产品系统等）打包在一个进程内的架构方式，微服务架构将应用拆分为一组功能独立的服务，通常服务对应于明确的API（此处的API建议和明确的协议绑定起来，如REST），通常服务是独立部署在多个进程中的。从应用能力完整的角度来看，单个进程内的函数调用与进程间的API调用都由应用本身的能力驱动，内在的逻辑是一致的。
因此，微服务架构是对应用构建方式的再思考成果，可以说是架构方式的一种深度evolution，而不是revolution。这种evolution本身的驱动力很难一一表述，大体上可以列举为（1）云化计算的普及，（2）现实世界的大规模信息化导致数据、计算的快速膨胀（可以粗糙地类比为手工作坊完成端到端产品生产到社会化大规模生产产品各部分由单个的工厂生产）已经不允许将所有职能放在单个进程内计算，（3）软件工程方法（包括运维诉求）的发展要求对软件整个lifecycle更加精细化管理，单个庞大的应用无法与工程方法管理单元进行映射，（4）平台化战略的推动（这与第一点有关联），大的企业不再提供endpoint的服务，而是提供计算能力（包括业务计算，如创建订单、管理客户信息等）由3rd开发者/团体/公司去调用，这就推动了对应用整体能力的再抽象，再以标准化API发布，这种思维天然的推进了大应用模块化、组件化的思路。
因此微服务架构是一种对应用构建方式的再思考的演进总结，或者按照通俗说法是一种架构风格：） - 为什么需要微服务架构（Why）
从以上论述基本可以推导出微服务架构的价值了。归纳而言，面对大型云化应用的成功交付，必须寻求一种能够被把握的逻辑上的概念模型，能够有效的指导应用进行有序的开发、交付、运维。 - 怎么实施微服务架构（How）
具体方法同行分享很多，不一重复。总体上，面对应用的核心能力，进行抽象，主要是进行解耦、拆分（重点关注主数据的划分）。选择适合的分布式服务框架、解决好数据一致性以及高速增长的诉求、选择总结出有效的运维方法。 - 微服务与SOA（Contrast）
这一点可以参考学习Martin Fowler的论述。本质上还是围绕应用的能力论证什么是服务。 - 组件（Component）与微服务架构
这一节可以放入How章节，实施逻辑上的微服务架构，必须有对应的物理交付件。组件是粘合剂，服务纳入组件，组件定义好数据、API、配置项，甚至GUI等。因此，组件是一个很好的抽象，可以落地微服务架构，提供了一种恰当的软件单元粒度。
数据的意义
- 站在（企业）应用的视角看数据
如果用对企业活动的最后状态进行一个总结，那么这个总结就是数据。无论这个企业是否完整实施了信息化，即使企业用本子手工记录活动记录，数据也是其活动最终状态的高度归纳。因此有效对待数据，是非常有价值的。 - 数据的几种形态以及对数据的操作
从IT角度看数据，除了最终的状态记录外，计算过程中的数据也必须倾入巨大的关注。让数据的产生、计算更加有效率、更加准确。
（未完待续）
