谈到架构，微服务架构已然是时至今日必聊的一个话题，系统架构的选型与是否转型，不应该是为了微服务架构而架构，而是源于微服务架构自身是否更适合业务自身的需求，微服务架构的优势与所要付出的代价是否值得你，去做一次转变。 

    GIStack for Manager（捷泰天域睿图云GIS管理系统）在探索、挣扎、迭代、酝酿、分析了很久以后，勇敢的走向架构微服务化，正在实现一个GIStack for Manager架构的全面升级。

    从GIStack for Manger谈什么是微服务？它有什么好处？

    下图是GIStack for Manager实现方式示意，左侧是传统的整体式架构（单个巨型单元），右侧则是微服务：

GIStack for Manager实现方式示意图

    两种模式的区别在于第一种是整体式架构，只有一个大单元。第二种则由多个小单元构成，每个小单元都是独立的服务。

    此图足够细致，从中很容易找到微服务模式的吸引力所在：

    独立开发：小型的独立组件可由小型的独立团队构建。一个小组可以专门负责开发“Monitor”服务，不用去管其他服务。每个组件的功能变得简单，这样一来，开发人员了解组件的时间大大减少，更容易开发新功能。

    独立部署：每个单独的组件都可以独立部署。这样一来发布新功能的速度就更快，风险也更小。假设“GIS Service”组件修复了 bug 或者新增了功能，那么部署时并不会影响其他组件。

    独立扩展：每个组件可以独立地进行扩展。在产品发布时或者您需要进行扩展定制时，如您可以扩展“VM Services”组件，而不必扩展所有组件，这样一来扩展更具弹性并且降低了成本。

    可重用性：每个组件各自实现一个小的、特定的功能。这意味着它们可以很容易地适用于其他系统、服务或者产品。组件可以被其他业务单元使用，甚至可以改写成一个新的业务，从而为其他组提供转码服务。

    GIStack for Manager如何实现微服务？

    微服务架构的关键点就在于如何将分析业务与代码实现之间的关系，将功能拆分成一个个独立的单元，而这个小的单元即为一个微服务。那么多小的服务可称为微服务呢？是由代码的行数决定、还是重写的时间、还是业务功能？No，在进行设计过程中，我们遵循以下原则：

    低耦合、高内聚：一个服务完成一个独立的功能，保证服务的独立性和完整性。

    按团队结构：小规模团队维护，快速迭代。

    以下即为GIStack for Manager系统微服务架构粗略实现：

 GIStack for Manager系统微服务架构

    设计原则：

    服务独立性拆分原则：按照不同的服务功能进行拆分。

    前后端分离：便于代码维护、提高前端用户优化体验。

    无状态服务：有状态的业务服务改变为无状态的计算类服务，那么状态数据也就相应的迁移到对应的“有状态数据服务”中。

    Restful通信风格：无状态通信。

    微服务与容器、DevOps的关系？

    我相信很多关注微服务的读者们，经常看到微服务与容器、微服务与DevOps等关联在一起，那么系统的微服务架构与它们是什么关系呢？

    微服务与容器：完美的一对

    微服务技术和容器技术很容易勾搭到一起。容器可以实现服务发现 、负载均衡、分布式等特性，容器着眼于部署架构，或者说是微服务的宿主，负责提供所需的容器，具备弹性伸缩能力。微服务着眼于应用架构，负载掌控应用组件间的调用关系，通过应用组件的编排实现最终面向用户的功能。微服务架构所依赖的弹性、通信、轻量等需求容器恰好可以完美提供，因此微服务与容器可以说是完美的一对。

    微服务与DevOps：患难与共的挚交

    可以说微服务与DevOps是一种相辅相成的关系，使用微服务，第一步是要构建一个一体化的DevOps平台，否则，整个环境会变得非常的乱，它的架构与技术的复杂性与快速迭代性，为整个开发、测试和运维增加很多成本。通过一个DevOps平台可以帮助开发者快速打通设计、开发、测试与部署之间的矛盾，实现快速迭代。

    GIStack for Manager在系统实现过程中，全面实现了开发测试的持续集成。快速跟进需求，时刻为快速用户交付进行着。