本文来自 fairjm@图灵社区 转截请注明出处


现实情况,软件开发不是一个定义和执行的线性过程,而是一个进化的过程,通过和用户交流学习、交付不断迭代。

很多传统的基于瀑布流方法的软件制品有以下的特征:

• 紧耦合:可能一个很细微的改动会影响整个应用并带来新的bug。   
• 有漏洞(Leaky)
• 抽象泄露:一个开发团队直接访问属于其他团队的数据。造成了数据之间的隐式依赖 一些组件的内部数据结构会泄露到整个应用中   巨石:单一源码库

而基于微服务的架构有以下的特征:

•  有约束的(Constrained):单一责任,范围狭窄。做一件事并把他做好。
•  松耦合
•  抽象:微服务对自己的数据结构和数据源完全掌控。
•  独立:开发 编译 部署都是独立的。

微服务的特性对于基于云的开发很重要。
基于云的应用通常有以下几个特征:

•  庞大而多样化的用户群:想要很快使用一些新特性。新特性的交付比较足够快。微服务允许因为很小所以允许特性被很快交付;
•  极高的在线时间需求  ;
•  不平等的资源需求:不同的微服务所需资源不对等。  

对于微服务,不同角色的职责:

•  架构师:有大局观,了解应该如何拆分微服务,微服务之间如何交互来解决问题;
•  软件开发者:写代码,了解使用什么语言和框架来交付微服务;
•  DevOps工程师:在所有环境下的服务部署和管理。每个环境下的一致性和可重复性。

2.1 架构师的故事:设计微服务架构

在项目中 架构师的角色是对于需要解决的问题提供一个工作模型(working model)
提供一个脚手架让开发去填。

2.1.1 分解商业问题

分解问题到几个关键的部分,然后在这些部分中寻找相互间的关系。

• 描述商业问题,记下主要的名词。
• 注意动词。标识着具体商业行为。  
• 找寻数据内聚。找到彼此间高度相关的数据

2.1.2 确定服务粒度

• 从一个较大的服务开始比较小的开始要好:可以从业务不断拆分。而一开始就很小容易造成微服务变成了数据服务。
• 关注服务间交互。
• 服务职责会随着你对问题域的理解发生改变。

一些不好的味道:
太粗了:表太多 测试用例太多 太多职责
太细了:相互依赖过于严重 服务变成了CRUD操作的集合

不断迭代演化,而不是一开始就拿出一个完美的设计。

2.1.3 服务接口

REST URI JSON 状态码 服务接口要易于理解和使用。

2.2 什么时候不要使用微服务

没有很好的自动化运维
服务器的开销
应用规模小 用户量小
多个数据源的复杂数据聚合和转换 记住在微服务间执行事务还没有标准存在

2.3 开发者的童话:使用Spring Boot和java构建微服务

为什么使用JSON:
轻量(对比SOAP的大量额外内容开销)
容易阅读和理解
默认的JS序列化协议

尽量早一点对建立URL的版本控制
mvn spring-boot:run

2.4 DevOps的故事:建立苛刻的运行时

写代码简单,保持运行难。
服务组装
启动
服务发现
监控

方法论:
https://12factor.net/