什么是微服务架构
简单地说， 微服务是系统架构上的一种设计风格， 它的主旨是将一个原本独立的系统拆分成多个小型服务，这些小型服务都在各自独立的进程中运行，服务之间通过基于HTTP的RESTful API进行通信协作。被拆分成的每一个小型服务都围绕着系统中的某一项或一些耦合度较高的业务功能进行构建， 并且每个服务都维护着自身的数据存储、业务开发、自动化测试案例以及独立部署机制。
微服务架构的优缺点
微服务的优点
· 每个微服务都很小，这样能够聚焦一个指定的业务功能或业务需求。
· 微服务能够被小团队单独开发，这个小团队是2到5人的开发人员组成。
· 微服务是松耦合的，是有功能意义的服务，无论是在开发阶段或部署阶段都是独立的。
· 微服务能使用不同的语言开发，如Java、Python、PHP、C#等。
· 微服务允许容易且灵活的方式集成自动部署，通过持续集成工具，如Jenkins, Travis CI等工具。
· 一个团队的新成员能够更快投入生产。
· 微服务易于被一个开发人员理解，修改和维护，这样小团队能够更关注自己的工作成果。无需通过合作才能体现价值。
· 微服务允许你利用融合最新技术。
· 微服务只是业务逻辑的代码，不会和HTML,CSS 或其他界面组件混合。
· 微服务能够即时被要求扩展。
· 微服务能部署中低端配置的服务器上。
· 易于和第三方应用系统集成。
· 每个微服务都有自己的存储能力，可以有自己的数据库，也可以有统一数据库。
微服务的缺点
· 微服务架构可能引入过多的操作；
· 需要提高DevOps应用技巧；
· 对于开发和运维带来一定的挑战，需要付出双倍的努力；
· 分布式系统比单体应用架构复杂，且难以管理；
· 对于故障诊断比较难，分布式部署跟踪比单体架构复杂；
· 当服务数量增加，管理复杂性增加。
微服务架构在工业应用上的实战
下面以格创东智在某工业生产行业客户进行了微服务架构的实际落地案例进行说明。目前该公司的微服务架构如下图所示。
该公司拥有MES、EDA、RPT、SPC、OEE、FDC等应用，其中查询、分析类应用已经移植到微服务架构，使用的是Spring Cloud。
以RPT系统为例，使用SpringCloud之后，新增报表只需要开发有关业务逻辑的代码，其他配置、权限及校验代码都由微服务架构代劳，其开发和测试部署相较之前更加快捷，而且融合了Python技术，在某些特定场景下，系统运行效率也有可观的改善。
在异常分析系统中，之前使用的是Spark MLlib，但是在预测产品异常方面，Python的Keras效果更佳，在导入微服务架构后，可以很方便的使用Scala和Python的“混合”架构，系统的分析准确率得到了提升。
在移植过程中遇到了微服务的“边界”问题，在我们进行微服务架构设计和改造过程中，一个不可避免的问题是如何确定服务边界、如何进行服务识别，微服务的划分粒度究竟如何确认。我们可能会听到，服务既不能太大，也不能太小，当然这是一个笼统的概念。那么，问题来了，究竟多大是大，多小是小。
一个设计良好的服务应包含以下五个特征：
特征一：服务不与其他服务共享数据库
特征二：服务应包含尽可能少的数据库表
特征三：一个服务要么包含完整的业务含义，要么是放之四海皆通用的公共服务。
特征四：一个良好的服务应首先确保其数据可用性。
特征五：在一个业务系统中，一个服务只能是并且唯一的可信来源。
MES系统和EDA系统这一类与生产强相关的应用，业务逻辑复杂，耦合性强，进行服务“拆分”很难符合以上5个特征。所以暂时无法对其进行“拆分”。
综上所述，微服务架构比较适合制造业应用中查询、分析类应用，在生产控制这一类与生产强相关的应用上的作用还有待挖掘。
本文作者：
格创东智大数据系统集成部 王子超（转载请注明作者及来源）
