微服务容器化实践之初识微服务

软件架构

先来说说什么是软件架构，软件架构是在软件内部，经过综合各种因素的考量、权衡，选择特定的技术，将系统划分成不同的部分并使这些部分相互分工，彼此协作，为用户提供需要的价值。
一个良好的软件架构，需要考虑：1.业务需求。2.技术栈，项目团队所掌握的技术。3.成本，人力时间金钱成本。4.组织架构，组织内部其它项目组、平台可提供的资源。5.可拓展性。6.可维护性，一个新人通过学习可是否能够迅速适应项目的开发维护。

Java架构的进化过程。

一.单体架构

1.一层模式
最原始的写法是将所有前后台逻辑夹杂在一起，本人第一份工作参与的项目，技术栈是struts2/ibats/jsp，struts2中会有前端代码，jsp中会有java代码，维护及其费劲。

2. MVC三层架构模式
   最典型的SSH和SSM项目都是MVC三层架构的具体实践。
   MVC模式解决了代码的杂乱无章问题。
   3.前后端物理分离
   如采用dubbo将前后端从物理上进行分离。

二.单体架构的优势和挑战

优势
1.易于开发、调试
2.易于测试
3.易于部署 所有的代码都打在一个包里面
4.易于水平伸缩
挑战
1.代码膨胀，难以维护
2.构建、部署成本大
3.新人上手困难
4.创新困难
比如前端，换新技术新框架将伴随巨大的人力时间成本
5.可拓展性差

---

    基于单体架构本身的不足和劣势，互联网行业的快速发展，敏捷开发，精益方法深入人心，容器技术的成熟，微服务应运而生。

什么是微服务？

    使用一套小服务开发单个应用的方式，每个服务运行在独立的进程里，一般采用轻量级的通讯机制进行互联，并且可通过自动化的方式部署。
微服务既称“微”，什么才算“微”？
代码量？NO!开发时间？NO,影响开发时间的因素太多。
...
微，和空间、时间无关，微代表一种设计思想。

微服务的特征

• 单一职责
• 轻量级通信
• 相互隔离
  各服务之间有自己的数据库，各服务的技术实现可多样化，只要能提供固定的API

在具体的微服务项目中，原则上客户端可以访问每个微服务，
但是因为每个微服务不一定提供Rest Api，微服务的api修改、合并，就必须考虑客户端的兼容问题，微服务如果有上百个，客户端都来访问，会使客户端代码非常庞大。
所以更好的方式是在客户端和微服务之间采用Api GateWay

微服务的优势和不足

• 优势
  独立性，各服务相互独立，各数据库独立，易于水平伸缩和拓展
  敏捷性，易于修改和维护
  技术栈灵活，只要保证API接口不变

• 不足
  额外的工作，如服务的拆分
  数据一致性
  更高地沟通成本