微服务容器化实践之初识微服务
软件架构
先来说说什么是软件架构,软件架构是在软件内部,经过综合各种因素的考量、权衡,选择特定的技术,将系统划分成不同的部分并使这些部分相互分工,彼此协作,为用户提供需要的价值。
一个良好的软件架构,需要考虑:1.业务需求。2.技术栈,项目团队所掌握的技术。3.成本,人力时间金钱成本。4.组织架构,组织内部其它项目组、平台可提供的资源。5.可拓展性。6.可维护性,一个新人通过学习可是否能够迅速适应项目的开发维护。
Java架构的进化过程。
一.单体架构
1.一层模式
最原始的写法是将所有前后台逻辑夹杂在一起,本人第一份工作参与的项目,技术栈是struts2/ibats/jsp,struts2中会有前端代码,jsp中会有java代码,维护及其费劲。
- 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接口不变 -
不足
额外的工作,如服务的拆分
数据一致性
更高地沟通成本